Clean up docs dir layout.
3f5ef5a24IaQasQE2tyMxrfxskMmvw README
3f5ef5a2l4kfBYSQTUaOyyD76WROZQ README.CD
3f69d8abYB1vMyD_QVDvzxy5Zscf1A TODO
-4022a73cgxX1ryj1HgS-IwwB6NUi2A docs/HOWTOs/XenDebugger-HOWTO
3f9e7d53iC47UnlfORp9iC1vai6kWw docs/Makefile
-412f4bd9sm5mCQ8BkrgKcAKZGadq7Q docs/blkif-drivers-explained.txt
-3f9e7d60PWZJeVh5xdnk0nLUdxlqEA docs/eps/xenlogo.eps
-3f9e7d63lTwQbp2fnx7yY93epWS-eQ docs/figs/dummy
-3f9e7d564bWFB-Czjv1qdmE6o0GqNg docs/interface.tex
-3f9e7d58t7N6hjjBMxSn-NMxBphchA docs/style.tex
-410144afnSd2Yw68AHGO5gXu2m3y6A docs/user.tex
-40d6ccbfKKBq8jE0ula4eHEzBiQuDA docs/xen_config.html
-410a4c2bAO_m_l4RsiiPHnZ4ixHWbQ docs/xend.tex
+3f9e7d60PWZJeVh5xdnk0nLUdxlqEA docs/figs/xenlogo.eps
+4022a73cgxX1ryj1HgS-IwwB6NUi2A docs/misc/XenDebugger-HOWTO
+412f4bd9sm5mCQ8BkrgKcAKZGadq7Q docs/misc/blkif-drivers-explained.txt
+40d6ccbfKKBq8jE0ula4eHEzBiQuDA docs/misc/xen_config.html
+3f9e7d564bWFB-Czjv1qdmE6o0GqNg docs/src/interface.tex
+410144afnSd2Yw68AHGO5gXu2m3y6A docs/src/user.tex
+410a4c2bAO_m_l4RsiiPHnZ4ixHWbQ docs/src/xend.tex
3f9e7d5bz8BwYkNuwyiPVu7JJG441A docs/xenstyle.cls
3f815144d1vI2777JI-dO4wk49Iw7g extras/mini-os/Makefile
3f815144zTnCV5591ulIJQrpe5b-5Q extras/mini-os/README
docs/*.ps
docs/*.dvi
docs/*.toc
-docs/interface/*
-docs/user/*
-docs/xend/*
+docs/html/*
extras/mini-os/h/hypervisor-ifs
install
install/*
linux-*-xen0/*
linux-*-xenU/*
-linux-2.4.26-xen0
-linux-2.4.26-xenU
-linux-2.4.26.tar.gz
-linux-2.6.7-xenU
-linux-2.6.7.tar.bz2
linux-xen-sparse
netbsd-*-xen0
netbsd-*-xenU
+++ /dev/null
-Pervasive Debugging
-===================
-
-Alex Ho (alex.ho at cl.cam.ac.uk)
-
-Introduction
-------------
-
-The pervasive debugging project is leveraging Xen to
-debug distributed systems. We have added a gdb stub
-to Xen to allow for remote debugging of both Xen and
-guest operating systems. More information about the
-pervasive debugger is available at: http://www.cl.cam.ac.uk/netos/pdb
-
-
-Implementation
---------------
-
-The gdb stub communicates with gdb running over a serial line.
-The main entry point is pdb_handle_exception() which is invoked
-from: pdb_key_pressed() ('D' on the console)
- do_int3_exception() (interrupt 3: breakpoint exception)
- do_debug() (interrupt 1: debug exception)
-
-This accepts characters from the serial port and passes gdb
-commands to pdb_process_command() which implements the gdb stub
-interface. This file draws heavily from the kgdb project and
-sample gdbstub provided with gdb.
-
-The stub can examine registers, single step and continue, and
-read and write memory (in Xen, a domain, or a Linux process'
-address space). The debugger does not currently trace the
-current process, so all bets are off if context switch occurs
-in the domain.
-
-
-Setup
------
-
- +-------+ telnet +-----------+ serial +-------+
- | GDB |--------| nsplitd |--------| Xen |
- +-------+ +-----------+ +-------+
-
-To run pdb, Xen must be appropriately configured and
-a suitable serial interface attached to the target machine.
-GDB and nsplitd can run on the same machine.
-
-Xen Configuration
-
- Add the "pdb=xxx" option to your Xen boot command line
- where xxx is one of the following values:
- com1 gdb stub should communicate on com1
- com1H gdb stub should communicate on com1 (with high bit set)
- com2 gdb stub should communicate on com2
- com2H gdb stub should communicate on com2 (with high bit set)
-
- Symbolic debugging infomration is quite helpful too:
- xeno.bk/xen/arch/x86/Rules.mk
- add -g to CFLAGS to compile Xen with symbols
- xeno.bk/linux-2.4.27-xen-sparse/arch/xen/Makefile
- add -g to CFLAGS to compile Linux with symbols
-
- You may also want to consider dedicating a register to the
- frame pointer (disable the -fomit-frame-pointer compile flag).
-
- When booting Xen and domain 0, look for the console text
- "pdb: pervasive debugger" just before DOM0 starts up.
-
-Serial Port Configuration
-
- pdb expects to communicate with gdb using the serial port. Since
- this port is often shared with the machine's console output, pdb can
- discriminate its communication by setting the high bit of each byte.
-
- A new tool has been added to the source tree which splits
- the serial output from a remote machine into two streams:
- one stream (without the high bit) is the console and
- one stream (with the high bit stripped) is the pdb communication.
-
- See: xeno.bk/tools/misc/nsplitd
-
- nsplitd configuration
- ---------------------
- hostname$ more /etc/xinetd.d/nsplit
- service nsplit1
- {
- socket_type = stream
- protocol = tcp
- wait = no
- user = wanda
- server = /usr/sbin/in.nsplitd
- server_args = serial.cl.cam.ac.uk:wcons00
- disable = no
- only_from = 128.232.0.0/17 127.0.0.1
- }
-
- hostname$ egrep 'wcons00|nsplit1' /etc/services
- wcons00 9600/tcp # Wanda remote console
- nsplit1 12010/tcp # Nemesis console splitter ports.
-
- Note: nsplitd was originally written for the Nemesis project
- at Cambridge.
-
- After nsplitd accepts a connection on <port> (12010 in the above
- example), it starts listening on port <port + 1>. Characters sent
- to the <port + 1> will have the high bit set and vice versa for
- characters received.
-
- You can connect to the nsplitd using
- 'tools/misc/xencons <host> <port>'
-
-GDB 6.0
- pdb has been tested with gdb 6.0. It should also work with
- earlier versions.
-
-
-Usage
------
-
-1. Boot Xen and Linux
-2. Interrupt Xen by pressing 'D' at the console
- You should see the console message:
- (XEN) pdb_handle_exception [0x88][0x101000:0xfc5e72ac]
- At this point Xen is frozen and the pdb stub is waiting for gdb commands
- on the serial line.
-3. Attach with gdb
- (gdb) file xeno.bk/xen/xen
- Reading symbols from xeno.bk/xen/xen...done.
- (gdb) target remote <hostname>:<port + 1> /* contact nsplitd */
- Remote debugging using serial.srg:12131
- continue_cpu_idle_loop () at current.h:10
- warning: shared library handler failed to enable breakpoint
- (gdb) break __enter_scheduler
- Breakpoint 1 at 0xfc510a94: file schedule.c, line 330.
- (gdb) cont
- Continuing.
-
- Program received signal SIGTRAP, Trace/breakpoint trap.
- __enter_scheduler () at schedule.c:330
- (gdb) step
- (gdb) step
- (gdb) print next /* the variable prev has been optimized away! */
- $1 = (struct task_struct *) 0x0
- (gdb) delete
- Delete all breakpoints? (y or n) y
-4. You can add additional symbols to gdb
- (gdb) add-sym xeno.bk/linux-2.4.27-xen0/vmlinux
- add symbol table from file "xeno.bk/linux-2.4.27-xen0/vmlinux" at
- (y or n) y
- Reading symbols from xeno.bk/linux-2.4.27-xen0/vmlinux...done.
- (gdb) x/s cpu_vendor_names[0]
- 0xc01530d2 <cpdext+62898>: "Intel"
- (gdb) break free_uid
- Breakpoint 2 at 0xc0012250
- (gdb) cont
- Continuing. /* run a command in domain 0 */
-
- Program received signal SIGTRAP, Trace/breakpoint trap.
- free_uid (up=0xbffff738) at user.c:77
-
- (gdb) print *up
- $2 = {__count = {counter = 0}, processes = {counter = 135190120}, files = {
- counter = 0}, next = 0x395, pprev = 0xbffff878, uid = 134701041}
- (gdb) finish
- Run till exit from #0 free_uid (up=0xbffff738) at user.c:77
-
- Program received signal SIGTRAP, Trace/breakpoint trap.
- release_task (p=0xc2da0000) at exit.c:51
- (gdb) print *p
- $3 = {state = 4, flags = 4, sigpending = 0, addr_limit = {seg = 3221225472},
- exec_domain = 0xc016a040, need_resched = 0, ptrace = 0, lock_depth = -1,
- counter = 1, nice = 0, policy = 0, mm = 0x0, processor = 0,
- cpus_runnable = 1, cpus_allowed = 4294967295, run_list = {next = 0x0,
- prev = 0x0}, sleep_time = 18995, next_task = 0xc017c000,
- prev_task = 0xc2f94000, active_mm = 0x0, local_pages = {next = 0xc2da0054,
- prev = 0xc2da0054}, allocation_order = 0, nr_local_pages = 0,
- ...
-5. To resume Xen, enter the "continue" command to gdb.
- This sends the packet $c#63 along the serial channel.
-
- (gdb) cont
- Continuing.
-
-Debugging Multiple Domains & Processes
---------------------------------------
-
-pdb supports debugging multiple domains & processes. You can switch
-between different domains and processes within domains and examine
-variables in each.
-
-The pdb context identifies the current debug target. It is stored
-in the xen variable pdb_ctx and defaults to xen.
-
- target pdb_ctx.domain pdb_ctx.process
- ------ -------------- ---------------
- xen -1 -1
- guest os 0,1,2,... -1
- process 0,1,2,... 0,1,2,...
-
-Unfortunately, gdb doesn't understand debugging multiple process
-simultaneously (we're working on it), so at present you are limited
-to just one set of symbols for symbolic debugging. When debugging
-processes, pdb currently supports just Linux 2.4.
-
- define setup
- file xeno-clone/xeno.bk/xen/xen
- add-sym xeno-clone/xeno.bk/linux-2.4.27-xen0/vmlinux
- add-sym ~ach61/a.out
- end
-
-
-1. Connect with gdb as before. A couple of Linux-specific
- symbols need to be defined.
-
- (gdb) target remote <hostname>:<port + 1> /* contact nsplitd */
- Remote debugging using serial.srg:12131
- continue_cpu_idle_loop () at current.h:10
- warning: shared library handler failed to enable breakpoint
- (gdb) set pdb_pidhash_addr = &pidhash
- (gdb) set pdb_init_task_union_addr = &init_task_union
-
-2. The pdb context defaults to Xen and we can read Xen's memory.
- An attempt to access domain 0 memory fails.
-
- (gdb) print pdb_ctx
- $1 = {valid = 0, domain = -1, process = -1, ptbr = 1052672}
- (gdb) print hexchars
- $2 = "0123456789abcdef"
- (gdb) print cpu_vendor_names
- Cannot access memory at address 0xc0191f80
-
-3. Now we change to domain 0. In addition to changing pdb_ctx.domain,
- we need to change pdb_ctx.valid to signal pdb of the change.
- It is now possible to examine Xen and Linux memory.
-
- (gdb) set pdb_ctx.domain=0
- (gdb) set pdb_ctx.valid=1
- (gdb) print hexchars
- $3 = "0123456789abcdef"
- (gdb) print cpu_vendor_names
- $4 = {0xc0158b46 "Intel", 0xc0158c37 "Cyrix", 0xc0158b55 "AMD",
- 0xc0158c3d "UMC", 0xc0158c41 "NexGen", 0xc0158c48 "Centaur",
- 0xc0158c50 "Rise", 0xc0158c55 "Transmeta"}
-
-4. Now change to a process within domain 0. Again, we need to
- change pdb_ctx.valid in addition to pdb_ctx.process.
-
- (gdb) set pdb_ctx.process=962
- (gdb) set pdb_ctx.valid =1
- (gdb) print pdb_ctx
- $1 = {valid = 0, domain = 0, process = 962, ptbr = 52998144}
- (gdb) print aho_a
- $2 = 20
-
-5. Now we can read the same variable from another process running
- the same executable in another domain.
-
- (gdb) set pdb_ctx.domain=1
- (gdb) set pdb_ctx.process=1210
- (gdb) set pdb_ctx.valid=1
- (gdb) print pdb_ctx
- $3 = {valid = 0, domain = 1, process = 1210, ptbr = 70574080}
- (gdb) print aho_a
- $4 = 27
-
-
-Some Helpful .gdbinit Commands
-------------------------------
-
-define setup
- file .../install/boot/xen-syms
- add-sym .../install/boot/vmlinux-syms-2.4.27-xen0
- add-sym /homes/aho/a.out
-end
-document setup
- load symbols for xen, xenolinux (dom 0), and "a.out"
-end
-
-define setup-linux
- set pdb_pidhash_addr = &pidhash
- set pdb_init_task_union_addr = &init_task_union
-
- set task_struct_mm_offset = (void *)&(init_task_union.task.mm) - (void *)&(init_task_union.task)
- set task_struct_next_task_offset = (void *)&(init_task_union.task.next_task) - (void *)&(init_task_union.task)
- set task_struct_pid_offset = (void *)&(init_task_union.task.pid) - (void *)&(init_task_union.task)
- set task_struct_pidhash_next_offset = (void *)&(init_task_union.task.pidhash_next) - (void *)&(init_task_union.task)
- set task_struct_comm_offset = (void *)&(init_task_union.task.comm) - (void *)&(init_task_union.task)
- set task_struct_comm_length = sizeof (init_task_union.task.comm)
-
- set mm_struct_pgd_offset = sizeof (struct vm_area_struct *) * 2 + sizeof (rb_root_t)
-end
-document setup-linux
- define various xenolinux specific offsets and sizes in pdb
-end
-
-
-
-
-Changes
--------
-
-04.07.15 aho .gdbinit
-04.02.05 aho creation
-04.03.31 aho add description on debugging multiple domains
-# Generic LaTeX makefile.
-#
-# Xfig and tgif diagrams should be in the fig/ subdirectory.
-# DOCUMENTS should be a list of the target Postscript files.
-
-DOCUMENTS = interface.ps interface.pdf interface.html user.ps \
- user.pdf user.html xend.ps xend.pdf xend.html
+DOC_TEX := $(wildcard src/*.tex)
+DOC_PS := $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
+DOC_PDF := $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
+DOC_HTML := $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX))
GFX = $(patsubst %.obj, %.eps, $(wildcard figs/*.obj))
GFX += $(patsubst %.fig, %.eps, $(wildcard figs/*.fig))
-all: $(DOCUMENTS)
+all: ps pdf html
+ rm -f *.aux *.dvi *.bbl *.blg *.glo *.idx *.ilg *.log *.ind *.toc
+
+ps: $(DOC_PS)
+
+pdf: $(DOC_PDF)
-pristine: clean
- rm -f $(DOCUMENTS)
+html: $(DOC_HTML)
clean:
- rm -f .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~
- rm -f *.ilg *.log *.ind *.toc *.bak core
- rm -f figs/*.eps $(DOCUMENTS)
- rm -rf user/
- rm -rf interface/
+ rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~
+ rm -rf *.ilg *.log *.ind *.toc *.bak core
+ rm -rf $(GFX) ps pdf html
-install: $(DOCUMENTS)
+install: all
mkdir -p $(prefix)/usr/share/doc/xen
- cp -a $(DOCUMENTS) VBD-HOWTO.txt Xen-HOWTO.txt $(prefix)/usr/share/doc/xen
+ cp -a ps $(prefix)/usr/share/doc/xen
+ cp -a pdf $(prefix)/usr/share/doc/xen
+ cp -a html $(prefix)/usr/share/doc/xen
-%.pdf: %.ps
- ps2pdf $< $@
+pdf/%.pdf: ps/%.ps
+ mkdir -p pdf ; ps2pdf $< $@
-%.ps: %.dvi $(GFX)
- dvips -Ppdf -G0 -o $@ $<
+ps/%.ps: %.dvi $(GFX)
+ mkdir -p ps ; dvips -Ppdf -G0 -o $@ $<
-%.dvi: %.tex
- latex $* >/dev/null
- if [ -e $*.toc ] ; then latex $* >/dev/null ; fi
+%.dvi: src/%.tex
+ latex $< >/dev/null
+ if [ -e $*.toc ] ; then latex $< >/dev/null ; fi
%.eps: %.fig
fig2dev -L eps $< $@
%.eps: %.obj
tgif -print -color -eps $<
-%.html: %.tex
- latex2html --split 0 --nonavigation --noinfo --math $< 1>/dev/null 2>/dev/null
+html/%/index.html: src/%.tex
+ mkdir -p html/$*
+ latex2html -split 0 -nonavigation -noinfo -math -dir html/$* $< \
+ 1>/dev/null 2>/dev/null
+++ /dev/null
-=== How the Blkif Drivers Work ===
-Andrew Warfield
-andrew.warfield@cl.cam.ac.uk
-
-The intent of this is to explain at a fairly detailed level how the
-split device drivers work in Xen 1.3 (aka 2.0beta). The intended
-audience for this, I suppose, is anyone who intends to work with the
-existing blkif interfaces and wants something to help them get up to
-speed with the code in a hurry. Secondly though, I hope to break out
-the general mechanisms that are used in the drivers that are likely to
-be necessary to implement other drivers interfaces.
-
-As a point of warning before starting, it is worth mentioning that I
-anticipate much of the specifics described here changing in the near
-future. There has been talk about making the blkif protocol
-a bit more efficient than it currently is. Keir's addition of grant
-tables will change the current remapping code that is used when shared
-pages are initially set up.
-
-Also, writing other control interface types will likely need support
-from Xend, which at the moment has a steep learning curve... this
-should be addressed in the future.
-
-For more information on the driver model as a whole, read the
-"Reconstructing I/O" technical report
-(http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2004-xenngio.pdf).
-
-==== High-level structure of a split-driver interface ====
-
-Why would you want to write a split driver in the first place? As Xen
-is a virtual machine manager and focuses on isolation as an initial
-design principle, it is generally considered unwise to share physical
-access to devices across domains. The reasons for this are obvious:
-when device resources are shared, misbehaving code or hardware can
-result in the failure of all of the client applications. Moreover, as
-virtual machines in Xen are entire OSs, standard device drives that
-they might use cannot have multiple instantiations for a single piece
-of hardware. In light of all this, the general approach in Xen is to
-give a single virtual machine hardware access to a device, and where
-other VMs want to share the device, export a higher-level interface to
-facilitate that sharing. If you don't want to share, that's fine.
-There are currently Xen users actively exploring running two
-completely isolated X-Servers on a Xen host, each with it's own video
-card, keyboard, and mouse. In these situations, the guests need only
-be given physical access to the necessary devices and left to go on
-their own. However, for devices such as disks and network interfaces,
-where sharing is required, the split driver approach is a good
-solution.
-
-The structure is like this:
-
- +--------------------------+ +--------------------------+
- | Domain 0 (privileged) | | Domain 1 (unprivileged) |
- | | | |
- | Xend ( Application ) | | |
- | Blkif Backend Driver | | Blkif Frontend Driver |
- | Physical Device Driver | | |
- +--------------------------+ +--------------------------+
- +--------------------------------------------------------+
- | X E N |
- +--------------------------------------------------------+
-
-
-The Blkif driver is in two parts, which we refer to as frontend (FE)
-and a backend (BE). Together, they serve to proxy device requests
-between the guest operating system in an unprivileged domain, and the
-physical device driver in the physical domain. An additional benefit
-to this approach is that the FE driver can provide a single interface
-for a whole class of physical devices. The blkif interface mounts
-IDE, SCSI, and our own VBD-structured disks, independent of the
-physical driver underneath. Moreover, supporting additional OSs only
-requires that a new FE driver be written to connect to the existing
-backend.
-
-==== Inter-Domain Communication Mechanisms ====
-
-===== Event Channels =====
-
-Before getting into the specifics of the block interface driver, it is
-worth discussing the mechanisms that are used to communicate between
-domains. Two mechanisms are used to allow the construction of
-high-performance drivers: event channels and shared-memory rings.
-
-Event channels are an asynchronous interdomain notification
-mechanism. Xen allows channels to be instantiated between two
-domains, and domains can request that a virtual irq be attached to
-notifications on a given channel. The result of this is that the
-frontend domain can send a notification on an event channel, resulting
-in an interrupt entry into the backend at a later time.
-
-The event channel between two domains is instantiated in the Xend code
-during driver startup (described later). Xend's channel.py
-(tools/python/xen/xend/server/channel.py) defines the function
-
-
-def eventChannel(dom1, dom2):
- return xc.evtchn_bind_interdomain(dom1=dom1, dom2=dom2)
-
-
-which maps to xc_evtchn_bind_interdomain() in tools/libxc/xc_evtchn.c,
-which in turn generates a hypercall to Xen to patch the event channel
-between the domains. Only a privileged domain can request the
-creation of an event channel.
-
-Once the event channel is created in Xend, its ends are passed to both the
-front and backend domains over the control channel. The end that is
-passed to a domain is just an integer "port" uniquely identifying the
-event channel's local connection to that domain. An example of this
-setup code is in linux-2.6.x/drivers/xen/blkfront/blkfront.c in
-blkif_status_change, which receives several status change events as
-the driver starts up. It is passed an event channel end in a
-BLKIF_INTERFACE_STATUS_CONNECTED message, and patches it in like this:
-
-
- blkif_evtchn = status->evtchn;
- blkif_irq = bind_evtchn_to_irq(blkif_evtchn);
- if ( (rc = request_irq(blkif_irq, blkif_int,
- SA_SAMPLE_RANDOM, "blkif", NULL)) )
- printk(KERN_ALERT"blkfront request_irq failed (%ld)\n",rc);
-
-
-This code associates a virtual irq with the event channel, and
-attaches the function blkif_int() as an interrupt handler for that
-irq. blkif_int() simply handles the notification and returns, it does
-not need to interact with the channel at all.
-
-An example of generating a notification can also be seen in blkfront.c:
-
-
-static inline void flush_requests(void)
-{
- DISABLE_SCATTERGATHER();
- wmb(); /* Ensure that the frontend can see the requests. */
- blk_ring->req_prod = req_prod;
- notify_via_evtchn(blkif_evtchn);
-}
-}}}
-
-notify_via_evtchn issues a hypercall to set the event waiting flag on
-the other domain's end of the channel.
-
-===== Communication Rings =====
-
-Event channels are strictly a notification mechanism between domains.
-To move large chunks of data back and forth, Xen allows domains to
-share pages of memory. We use communication rings as a means of
-managing access to a shared memory page for message passing between
-domains. These rings are not explicitly a mechanism of Xen, which is
-only concerned with the actual sharing of the page and not how it is
-used, they are however worth discussing as they are used in many
-places in the current code and are a useful model for communicating
-across a shared page.
-
-A shared page is set up by a guest first allocating and passing the
-address of a page in its own address space to the backend driver.
-
-
- blk_ring = (blkif_ring_t *)__get_free_page(GFP_KERNEL);
- blk_ring->req_prod = blk_ring->resp_prod = resp_cons = req_prod = 0;
- ...
- /* Construct an interface-CONNECT message for the domain controller. */
- cmsg.type = CMSG_BLKIF_FE;
- cmsg.subtype = CMSG_BLKIF_FE_INTERFACE_CONNECT;
- cmsg.length = sizeof(blkif_fe_interface_connect_t);
- up.handle = 0;
- up.shmem_frame = virt_to_machine(blk_ring) >> PAGE_SHIFT;
- memcpy(cmsg.msg, &up, sizeof(up));
-
-
-blk_ring will be the shared page. The producer and consumer pointers
-are then initialised (these will be discussed soon), and then the
-machine address of the page is send to the backend via a control
-channel to Xend. This control channel itself uses the notification
-and shared memory mechanisms described here, but is set up for each
-domain automatically at startup.
-
-The backend, which is a privileged domain then takes the page address
-and maps it into its own address space (in
-linux26/drivers/xen/blkback/interface.c:blkif_connect()):
-
-
-void blkif_connect(blkif_be_connect_t *connect)
-
- ...
- unsigned long shmem_frame = connect->shmem_frame;
- ...
-
- if ( (vma = get_vm_area(PAGE_SIZE, VM_IOREMAP)) == NULL )
- {
- connect->status = BLKIF_BE_STATUS_OUT_OF_MEMORY;
- return;
- }
-
- prot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED);
- error = direct_remap_area_pages(&init_mm, VMALLOC_VMADDR(vma->addr),
- shmem_frame<<PAGE_SHIFT, PAGE_SIZE,
- prot, domid);
-
- ...
-
- blkif->blk_ring_base = (blkif_ring_t *)vma->addr
-}}}
-
-The machine address of the page is passed in the shmem_frame field of
-the connect message. This is then mapped into the virtual address
-space of the backend domain, and saved in the blkif structure
-representing this particular backend connection.
-
-NOTE: New mechanisms will be added very shortly to allow domains to
-explicitly grant access to their pages to other domains. This "grant
-table" support is in the process of being added to the tree, and will
-change the way a shared page is set up. In particular, it will remove
-the need of the remapping domain to be privileged.
-
-Sending data across shared rings:
-
-Shared rings avoid the potential for write interference between
-domains in a very cunning way. A ring is partitioned into a request
-and a response region, and domains only work within their own space.
-This can be thought of as a double producer-consumer ring -- the ring
-is described by four pointers into a circular buffer of fixed-size
-records. Pointers may only advance, and may not pass one another.
-
-
- rsp_cons----+
- V
- +----+----+----+----+----+----+----+
- | | | free |RSP1|RSP2|
- +----+----+----+----+----+----+----+
- req_prod->| | --------> |RSP3|
- +----+ +----+
- |REQ8| | |<-rsp_prod
- +----+ +----+
- |REQ7| | |
- +----+ +----+
- |REQ6| <-------- | |
- +----+----+----+----+----+----+----+
- |REQ5|REQ4| free | | |
- +----+----+----+----+----+----+----+
- req_cons---------^
-
-
-
-By adopting the convention that every request will receive a response,
-not all four pointers need be shared and flow control on the ring
-becomes very easy to manage. Each domain manages its own
-consumer pointer, and the two producer pointers are visible to both (Xen/include/hypervisor-ifs/io/blkif.h):
-
-
-
-/* NB. Ring size must be small enough for sizeof(blkif_ring_t) <=PAGE_SIZE.*/
- #define BLKIF_RING_SIZE 64
-
- ...
-
-/*
- * We use a special capitalised type name because it is _essential_ that all
- * arithmetic on indexes is done on an integer type of the correct size.
- */
-typedef u32 BLKIF_RING_IDX;
-
-/*
- * Ring indexes are 'free running'. That is, they are not stored modulo the
- * size of the ring buffer. The following macro converts a free-running counter
- * into a value that can directly index a ring-buffer array.
- */
-#define MASK_BLKIF_IDX(_i) ((_i)&(BLKIF_RING_SIZE-1))
-
-typedef struct {
- BLKIF_RING_IDX req_prod; /* 0: Request producer. Updated by front-end. */
- BLKIF_RING_IDX resp_prod; /* 4: Response producer. Updated by back-end. */
- union { /* 8 */
- blkif_request_t req;
- blkif_response_t resp;
- } PACKED ring[BLKIF_RING_SIZE];
-} PACKED blkif_ring_t;
-
-
-
-As shown in the diagram above, the rules for using a shared memory
-ring are simple.
-
- 1. A ring is full when a domain's producer and consumer pointers are
- equal (e.g. req_prod == resp_cons). In this situation, the
- consumer pointer must be advanced. Furthermore, if the consumer
- pointer is equal to the other domain's producer pointer,
- (e.g. resp_cons = resp_prod), then the other domain has all the
- buffers.
-
-2. Producer pointers point to the next buffer that will be written to.
- (So blk_ring[MASK_BLKIF_IDX(req_prod)] should not be consumed.)
-
-3. Consumer pointers point to a valid message, so long as they are not
- equal to the associated producer pointer.
-
-4. A domain should only ever write to the message pointed
- to by its producer index, and read from the message at it's
- consumer. More generally, the domain may be thought of to have
- exclusive access to the messages between its consumer and producer,
- and should absolutely not read or write outside this region.
-
-In general, drivers keep a private copy of their producer pointer and
-then set the shared version when they are ready for the other end to
-process a set of messages. Additionally, it is worth paying attention
-to the use of memory barriers (rmb/wmb) in the code, to ensure that
-rings that are shared across processors behave as expected.
-
-==== Structure of the Blkif Drivers ====
-
-Now that the communications primitives have been discussed, I'll
-quickly cover the general structure of the blkif driver. This is
-intended to give a high-level idea of what is going on, in an effort
-to make reading the code a more approachable task.
-
-There are three key software components that are involved in the blkif
-drivers (not counting Xen itself). The frontend and backend driver,
-and Xend, which coordinates their initial connection. Xend may also
-be involved in control-channel signalling in some cases after startup,
-for instance to manage reconnection if the backend is restarted.
-
-===== Frontend Driver Structure =====
-
-The frontend domain uses a single event channel and a shared memory
-ring to trade control messages with the backend. These are both setup
-during domain startup, which will be discussed shortly. The shared
-memory ring is called blkif_ring, and the private ring indexes are
-resp_cons, and req_prod. The ring is protected by blkif_io_lock.
-Additionally, the frontend keeps a list of outstanding requests in
-rec_ring[]. These are uniquely identified by a guest-local id number,
-which is associated with each request sent to the backend, and
-returned with the matching responses. Information about the actual
-disks are stored in major_info[], of which only the first nr_vbds
-entries are valid. Finally, the global 'recovery' indicates that the
-connection between the backend and frontend drivers has been broken
-(possibly due to a backend driver crash) and that the frontend is in
-recovery mode, in which case it will attempt to reconnect and reissue
-outstanding requests.
-
-The frontend driver is single-threaded and after setup is entered only
-through three points: (1) read/write requests from the XenLinux guest
-that it is a part of, (2) interrupts from the backend driver on its
-event channel (blkif_int()), and (3) control messages from Xend
-(blkif_ctrlif_rx).
-
-===== Backend Driver Structure =====
-
-The backend driver is slightly more complex as it must manage any
-number of concurrent frontend connections. For each domain it
-manages, the backend driver maintains a blkif structure, which
-describes all the connection and disk information associated with that
-particular domain. This structure is associated with the interrupt
-registration, and allows the backend driver to have immediate context
-when it takes a notification from some domain.
-
-All of the blkif structures are stored in a hash table (blkif_hash),
-which is indexed by a hash of the domain id, and a "handle", really a
-per-domain blkif identifier, in case it wants to have multiple connections.
-
-The per-connection blkif structure is of type blkif_t. It contains
-all of the communication details (event channel, irq, shared memory
-ring and indexes), and blk_ring_lock, which is the backend mutex on
-the shared ring. The structure also contains vbd_rb, which is a
-red-black tree, containing an entry for each device/partition that is
-assigned to that domain. This structure is filled by xend passing
-disk information to the backend at startup, and is protected by
-vbd_lock. Finally, the blkif struct contains a status field, which
-describes the state of the connection.
-
-The backend driver spawns a kernel thread at startup
-(blkio_schedule()), which handles requests to and from the actual disk
-device drivers. This scheduler thread maintains a list of blkif
-structures that have pending requests, and services them round-robin
-with a maximum per-round request limit. blkifs are added to the list
-in the interrupt handler (blkif_be_int()) using
-add_to_blkdev_list_tail(), and removed in the scheduler loop after
-calling do_block_io_op(), which processes a batch of requests. The
-scheduler thread is explicitly activated at several points in the code
-using maybe_trigger_blkio_schedule().
-
-Pending requests between the backend driver and the physical device
-drivers use another ring, pending_ring. Requests are placed in this
-ring in the scheduler thread and issued to the device. A completion
-callback, end_block_io_op, indicates that requests have been serviced
-and generates a response on the appropriate blkif ring. pending
-reqs[] stores a list of outstanding requests with the physical drivers.
-
-So, control entries to the backend are (1) the blkio scheduler thread,
-which sends requests to the real device drivers, (2) end_block_io_op,
-which is called as serviced requests complete, (3) blkif_be_int()
-handles notifications from the frontend drivers in other domains, and
-(4) blkif_ctrlif_rx() handles control messages from xend.
-
-==== Driver Startup ====
-
-Prior to starting a new guest using the frontend driver, the backend
-will have been started in a privileged domain. The backend
-initialisation code initialises all of its data structures, such as
-the blkif hash table, and starts the scheduler thread as a kernel
-thread. It then sends a driver status up message to let xend know it
-is ready to take frontend connections.
-
-When a new domain that uses the blkif frontend driver is started,
-there are a series of interactions between it, xend, and the specified
-backend driver. These interactions are as follows:
-
-The domain configuration given to xend will specify the backend domain
-and disks that the new guest is to use. Prior to actually running the
-domain, xend and the backend driver interact to setup the initial
-blkif record in the backend.
-
-(1) Xend sends a BLKIF_BE_CREATE message to backend.
-
- Backend does blkif_create(), having been passed FE domid and handle.
- It creates and initialises a new blkif struct, and puts it in the
- hash table.
- It then returns a STATUS_OK response to xend.
-
-(2) Xend sends a BLKIF_BE_VBD_CREATE message to the backend.
-
- Backend adds a vbd entry in the red-black tree for the
- specified (dom, handle) blkif entry.
- Sends a STATUS_OK response.
-
-(3) Xend sends a BLKIF_BE_VBD_GROW message to the backend.
-
- Backend takes the physical device information passed in the
- message and assigns them to the newly created vbd struct.
-
-(2) and (3) repeat as any additional devices are added to the domain.
-
-At this point, the backend has enough state to allow the frontend
-domain to start. The domain is run, and eventually gets to the
-frontend driver initialisation code. After setting up the frontend
-data structures, this code continues the communications with xend and
-the backend to negotiate a connection:
-
-(4) Frontend sends Xend a BLKIF_FE_DRIVER_STATUS_CHANGED message.
-
- This message tells xend that the driver is up. The init function
- now spin-waits until driver setup is complete in order to prevent
- Linux from attempting to boot before the disks are connected.
-
-(5) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
-
- This message specifies that the interface is now disconnected
- (instead of closed).
- The domain updates it's state, and allocates the shared blk_ring
- page. Next,
-
-(6) Frontend sends Xend a BLKIF_INTERFACE_CONNECT message
-
- This message specifies the domain and handle, and includes the
- address of the newly created page.
-
-(7) Xend sends the backend a BLKIF_BE_CONNECT message
-
- The backend fills in the blkif connection information, maps the
- shared page, and binds an irq to the event channel.
-
-(8) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
-
- This message takes the frontend driver to a CONNECTED state, at
- which point it binds an irq to the event channel and calls
- xlvbd_init to initialise the individual block devices.
-
-The frontend Linux is stall spin waiting at this point, until all of
-the disks have been probed. Messaging now is directly between the
-front and backend domain using the new shared ring and event channel.
-
-(9) The frontend sends a BLKIF_OP_PROBE directly to the backend.
-
- This message includes a reference to an additional page, that the
- backend can use for it's reply. The backend responds with an array
- of the domains disks (as vdisk_t structs) on the provided page.
-
-The frontend now initialises each disk, calling xlvbd_init_device()
-for each one.
+++ /dev/null
-%!PS-Adobe-3.0 EPSF-3.0
-%%Creator: (ImageMagick)
-%%Title: (/homes/kaf24/xenlogo.eps)
-%%CreationDate: (Tue Oct 28 13:52:11 2003)
-%%BoundingBox: 155 324 445 461
-%%DocumentData: Clean7Bit
-%%LanguageLevel: 1
-%%Pages: 1
-%%EndComments
-
-%%BeginDefaults
-%%EndDefaults
-
-%%BeginProlog
-%
-% Display a color image. The image is displayed in color on
-% Postscript viewers or printers that support color, otherwise
-% it is displayed as grayscale.
-%
-/DirectClassPacket
-{
- %
- % Get a DirectClass packet.
- %
- % Parameters:
- % red.
- % green.
- % blue.
- % length: number of pixels minus one of this color (optional).
- %
- currentfile color_packet readhexstring pop pop
- compression 0 eq
- {
- /number_pixels 3 def
- }
- {
- currentfile byte readhexstring pop 0 get
- /number_pixels exch 1 add 3 mul def
- } ifelse
- 0 3 number_pixels 1 sub
- {
- pixels exch color_packet putinterval
- } for
- pixels 0 number_pixels getinterval
-} bind def
-
-/DirectClassImage
-{
- %
- % Display a DirectClass image.
- %
- systemdict /colorimage known
- {
- columns rows 8
- [
- columns 0 0
- rows neg 0 rows
- ]
- { DirectClassPacket } false 3 colorimage
- }
- {
- %
- % No colorimage operator; convert to grayscale.
- %
- columns rows 8
- [
- columns 0 0
- rows neg 0 rows
- ]
- { GrayDirectClassPacket } image
- } ifelse
-} bind def
-
-/GrayDirectClassPacket
-{
- %
- % Get a DirectClass packet; convert to grayscale.
- %
- % Parameters:
- % red
- % green
- % blue
- % length: number of pixels minus one of this color (optional).
- %
- currentfile color_packet readhexstring pop pop
- color_packet 0 get 0.299 mul
- color_packet 1 get 0.587 mul add
- color_packet 2 get 0.114 mul add
- cvi
- /gray_packet exch def
- compression 0 eq
- {
- /number_pixels 1 def
- }
- {
- currentfile byte readhexstring pop 0 get
- /number_pixels exch 1 add def
- } ifelse
- 0 1 number_pixels 1 sub
- {
- pixels exch gray_packet put
- } for
- pixels 0 number_pixels getinterval
-} bind def
-
-/GrayPseudoClassPacket
-{
- %
- % Get a PseudoClass packet; convert to grayscale.
- %
- % Parameters:
- % index: index into the colormap.
- % length: number of pixels minus one of this color (optional).
- %
- currentfile byte readhexstring pop 0 get
- /offset exch 3 mul def
- /color_packet colormap offset 3 getinterval def
- color_packet 0 get 0.299 mul
- color_packet 1 get 0.587 mul add
- color_packet 2 get 0.114 mul add
- cvi
- /gray_packet exch def
- compression 0 eq
- {
- /number_pixels 1 def
- }
- {
- currentfile byte readhexstring pop 0 get
- /number_pixels exch 1 add def
- } ifelse
- 0 1 number_pixels 1 sub
- {
- pixels exch gray_packet put
- } for
- pixels 0 number_pixels getinterval
-} bind def
-
-/PseudoClassPacket
-{
- %
- % Get a PseudoClass packet.
- %
- % Parameters:
- % index: index into the colormap.
- % length: number of pixels minus one of this color (optional).
- %
- currentfile byte readhexstring pop 0 get
- /offset exch 3 mul def
- /color_packet colormap offset 3 getinterval def
- compression 0 eq
- {
- /number_pixels 3 def
- }
- {
- currentfile byte readhexstring pop 0 get
- /number_pixels exch 1 add 3 mul def
- } ifelse
- 0 3 number_pixels 1 sub
- {
- pixels exch color_packet putinterval
- } for
- pixels 0 number_pixels getinterval
-} bind def
-
-/PseudoClassImage
-{
- %
- % Display a PseudoClass image.
- %
- % Parameters:
- % class: 0-PseudoClass or 1-Grayscale.
- %
- currentfile buffer readline pop
- token pop /class exch def pop
- class 0 gt
- {
- currentfile buffer readline pop
- token pop /depth exch def pop
- /grays columns 8 add depth sub depth mul 8 idiv string def
- columns rows depth
- [
- columns 0 0
- rows neg 0 rows
- ]
- { currentfile grays readhexstring pop } image
- }
- {
- %
- % Parameters:
- % colors: number of colors in the colormap.
- % colormap: red, green, blue color packets.
- %
- currentfile buffer readline pop
- token pop /colors exch def pop
- /colors colors 3 mul def
- /colormap colors string def
- currentfile colormap readhexstring pop pop
- systemdict /colorimage known
- {
- columns rows 8
- [
- columns 0 0
- rows neg 0 rows
- ]
- { PseudoClassPacket } false 3 colorimage
- }
- {
- %
- % No colorimage operator; convert to grayscale.
- %
- columns rows 8
- [
- columns 0 0
- rows neg 0 rows
- ]
- { GrayPseudoClassPacket } image
- } ifelse
- } ifelse
-} bind def
-
-/DisplayImage
-{
- %
- % Display a DirectClass or PseudoClass image.
- %
- % Parameters:
- % x & y translation.
- % x & y scale.
- % label pointsize.
- % image label.
- % image columns & rows.
- % class: 0-DirectClass or 1-PseudoClass.
- % compression: 0-none or 1-RunlengthEncoded.
- % hex color packets.
- %
- gsave
- /buffer 512 string def
- /byte 1 string def
- /color_packet 3 string def
- /pixels 768 string def
-
- currentfile buffer readline pop
- token pop /x exch def
- token pop /y exch def pop
- x y translate
- currentfile buffer readline pop
- token pop /x exch def
- token pop /y exch def pop
- currentfile buffer readline pop
- token pop /pointsize exch def pop
- /Times-Roman findfont pointsize scalefont setfont
- x y scale
- currentfile buffer readline pop
- token pop /columns exch def
- token pop /rows exch def pop
- currentfile buffer readline pop
- token pop /class exch def pop
- currentfile buffer readline pop
- token pop /compression exch def pop
- class 0 gt { PseudoClassImage } { DirectClassImage } ifelse
- grestore
-} bind def
-%%EndProlog
-%%Page: 1 1
-%%PageBoundingBox: 155 324 445 461
-userdict begin
-DisplayImage
-155 324
-289.992 137.145
-12.000000
-302 143
-1
-1
-1
-8
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff8e6
-d4cec2b6b6aa9e9e9e9e9e9e9e9eb6b6b6c8cee0e6ffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffff2e0c8b6a49e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-aabccee6ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffff8e0c2aa9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb6ceecffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffffffffffffffffffffffff8dabc9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-aac8ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffe0bc9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaac8f2ffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffff8ceaa9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb6e0
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffffffffffffffffffffff2c29e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9eaadaffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffff2c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaadaffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffff8c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9eaadaffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffcea49e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb6e6ffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffe6aa9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9ec2f8ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffff8c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4e0ffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe6aa9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1acb6bac4c8c8d6d6d6d6d6d6
-d6cfc8c8bdbaafa89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9ebcf8ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffc89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea8b6c4
-cfd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8bdafa19e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaaecffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffff8b09e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9ea1afc1d2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6cbbaa89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ed4ffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeca49e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eafc1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfbaa59e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9ec2f8ffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1bacfd6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6c8af9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb0f8ffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffc89e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9ea5c1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfb39e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9ea4ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea5c1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cf
-b39e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4ecffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1bdd6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfaf9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4
-daffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9eb3d2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a59e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9edaffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea5c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d2b69e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9edaffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb3d2d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a59e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9ea4ecffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9ea1c4d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d2af9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4ecffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffda9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea8cbd6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6bd9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9ea4f8ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffe09e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eafd2
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-c8a19e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb0f8ffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeca49e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9eb3d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cba89e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec2ffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffff8b09e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec1d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d2a89e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9ed4ffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9ec1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d2a89e9e9e9e9e9e9e9e9e9e9e9e9e9e9eecffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffda9e
-9e9e8027272727272727272727272b353535353535353535353535353535353535353535
-353535353535add6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c85035353535353535322727272727272727272727
-272727272d3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f5fefffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffff2a49e9e9e9e45000000000000000000000000000000000000
-00000000000000000000000000000000000000001ac8d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad28000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00003fefffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffb69e9e9e9e9e9e27000000
-000000000000000000000000000000000000000000000000000000000000000000000050
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6930d0000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000007fffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffd49e9e9e9e9e9e9e9413000000000000000000000000000000000000000000000000
-000000000000000000000000000085d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d66b0000000000000000000000000000000000
-0000000000000000000000000000000000000000000000000000000fbfffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffff8a49e9e9e9e9e9e9e9e8009000000000000000000
-000000000000000000000000000000000000000000000000000000000dadd6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c83500000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000002fdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e
-9e9e9e9e6200000000000000000000000000000000000000000000000000000000000000
-0000000000000028c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6ad1a000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000006fffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9e4500000000000000000000000000000000
-0000000000000000000000000000000000000000000050d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6850d0000000000000000000000000000
-00000000000000000000000000000000000000000000000000000000000fafffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9e9e9e2b00
-000000000000000000000000000000000000000000000000000000000000000000000000
-0085d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65d0000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000002fcfffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe09e9e
-9e9e9e9e9e9e9e9e9e9e9ea8c81a00000000000000000000000000000000000000000000
-0000000000000000000000000000000dadd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6c83500000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000005fefffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffaa9e9e9e9e9e9e9e9e9e9e9e9e9ecbd6ad0d00000000000000
-00000000000000000000000000000000000000000000000000000000000028d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad1a000000000000000000000000
-00000000000000000000000000000000000000000000000000000000000000009fffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e
-9e9ebad6d6d6850000000000000000000000000000000000000000000000000000000000
-0000000000000000005dd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d685
-0d0000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000001fcfffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffaa9e9e9e9e9e9e9e9e9e9e9e9ea5d6d6d6d6d65d0000000000000000000000000000
-00000000000000000000000000000000000000000000000093d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d65d0000000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000049efffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6
-350000000000000000000000000000000000000000000000000000000000000000000000
-00000dbbd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c83500000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000004faa
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffb69e9e9e9e9e9e
-9e9e9e9e9e9eacd6d6d6d6d6d6d6c81a0000000000000000000000000000000000000000
-000000000000000000000000000000000028d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6ad1a000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000009769e9ee0ffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffff29e9e9e9e9e9e9e9e9e9e9e9e9ecbd6d6d6d6d6d6d6d6ad0d0000000000
-00000000000000000000000000000000000000000000000000000000000000005dd6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6850d0000000000000000000000000000000000000000
-00000000000000000000000000000000000000000000001d949e9e9eb6ffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9eb3d6d6
-d6d6d6d6d6d6d6d685000000000000000000000000000000000000000000000000000000
-000000000000000000000093d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65d0000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-459e9e9e9e9e9ef2ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffa49e
-9e9e9e9e9e9e9e9e9e9e9ecfd6d6d6d6d6d6d6d6d6d6d65d000000000000000000000000
-000000000000000000000000000000000000000000000000000dbbd6d6d6d6d6d6d6d6d6
-d6d6d6c83500000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000096c9e9e9e9e9e9e9ec8ffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e9eacd6d6d6d6d6d6d6d6d6d6d6
-d6d635000000000000000000000000000000000000000000000000000000000000000000
-0000000035d6d6d6d6d6d6d6d6d6d6d6ad1a000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000001d8a9e9e9e9e9e9e9e9eaa
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffbc9e9e9e9e9e9e9e9e9e9e
-9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6c81a000000000000000000000000000000000000
-000000000000000000000000000000000000006bd6d6d6d6d6d6d6d6d6850d0000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00003b949e9e9e9e9e9e9e9e9e9ee0ffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffff89e9e9e9e9e9e9e9e9e9e9e9ea5d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad0d000000
-00000000000000000000000000000000000000000000000000000000000000000000a0d6
-d6d6d6d6d6d65d0000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000d7b9e9e9e9e9e9e9e9e9e9e9e9ec2ffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e9ebdd6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d68500000000000000000000000000000000000000000000000000
-0000000000000000000000000dc8d6d6d6d6c83500000000000000000000000000000000
-0000000000000000000000000000000000000000000000000000001aadd6a59e9e9e9e9e
-9e9e9e9e9e9ea4ffffffffffffffdfbf8f7f5f3f3f1f0000000000000000000000000000
-001f3f3f5f7f8fbfcfffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbc9e9e9e9e9e
-9e9e9e9e9e9e9ed2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65000000000000000000000
-00000000000000000000000000000000000000000000000000000035d6d6d6ad0d000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000042c8d6d6bd9e9e9e9e9e9e9e9e9e9e9e9ee6ffcf9f5f3f000000000000000000
-0000000000000000000000000000000000000000000000002f5f8fcfffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbf8f7f
-3f3f0f000000000000000000003f3f7f9fdfffffffffffffffffffffffffffffffffffff
-ffffffffffffffffa49e9e9e9e9e9e9e9e9e9e9eafd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d62800000000000000000000000000000000000000000000000000000000000000
-0000000000006bd685000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000078d6d6d6d6cf9e9e9e9e9e9e9e9e9e9e9e6c47
-1f0000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000f4f9fdfffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffbf3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3fefffffffffff
-ffffffffffffffaf6f2f000000000000000000000000000000000000000000001f6fcfff
-ffffffffffffffffffffffffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9ec1d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c80d00000000000000000000000000000000
-000000000000000000000000000000000000000000350000000000000000000000000000
-00000000000000000000000000000000000000000000000000000000000da0d6d6d6d6d6
-d6a89e9e9e9e9e9e9e763b09000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000004f9fffffffffffffffffffff
-ffffffffffffffffffffffffffffff6f0000000000000000000000000000000000000000
-000000000000001fffffffffffffffffffff9f4f00000000000000000000000000000000
-000000000000000000000000003fafffffffffffffffffffffffffffffffffffffffffce
-9e9e9e9e9e9e9e9e9e9e9e9ed2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad0000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000035c8d6d6d6d6d6d6d6bd9e9e9e9e94621300000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000f7fefffffffffffffffffffffffffffffffffffffffffffff3f000000000000
-0000000000000000000000000000000000000000004fffffffffffffffdf6f0f00000000
-00000000000000000000000000000000000000000000000000000000003fdfffffffffff
-ffffffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9eafd6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6850000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000005dd6d6d6d6d6d6d6d6d6cf9e9e944f0900
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000f8fffffffffffffffffffffffffffff
-ffffffffffffff000000000000000000000000000000000000000000000000000000008f
-ffffffffffdf5f0000000000000000000000000000000000000000000000000000000000
-00000000000000000f9fffffffffffffffffffffffffffffffffff9e9e9e9e9e9e9e9e9e
-9e9e9ebdd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6500000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000d93d6d6d6
-d6d6d6d6d6d6d6d69b4f0900000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-2fcfffffffffffffffffffffffffffffffffffffbf000000000000000000000000000000
-00000000000000000000000000bfffffffef5f0000000000000000000000000000000000
-0000000000000000000000000000000000000000000000009fffffffffffffffffffffff
-ffffffffe69e9e9e9e9e9e9e9e9e9e9e9ecbd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6280000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000028bbd6d6d6d6d6d6d6d6d6d6d6850d00000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000f9fffffffffffffffffffffffffffffffffff8f00
-000000000000000000000000000000000000000000000000000000ffffff8f0f00000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000009fffffffffffffffffffffffffffffd49e9e9e9e9e9e9e9e9e9e9ea1d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c80d0000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000050c8d6d6d6d6d6d6d6d6d6d6ad3500
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000006fffffffff
-ffffffffffffffffffffffff5f0000000000000000000000000000000000000000000000
-000000003fffef3f00000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000bfffffffffffffffffffffffffffc89e9e9e
-9e9e9e9e9e9e9e9eafd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000000000000000000000000d85d6
-d6d6d6d6d6d6d6d6d6d66b00000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000005fffffffffffffffffffffffffffffff1f000000000000000000
-0000000000000000000000000000000000006fbf0f000000000000000000000000000000
-00000000000000000000000000000000000000000000000000000000000000001fffffff
-ffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d685000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000028add6d6d6d6d6d6d6d6d6d6c835000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000005fffffffffffffffffffff
-ffffffef000000000000000000000000000000000000000000000000000000003f000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000009fffffffffffffffffffffffffa49e9e9e9e9e9e9e9e9e9e9e
-c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d650000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000042c8d6d6d6d6d6d6d6d6d6d6ad
-0d0000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000007fffffffffffffffffffffffffaf000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000002fffffffffffffffffffff
-ffff9e9e9e9e9e9e9e9e9e9e9e9ed2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d628000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-78d6d6d6d6d6d6d6d6d6d6d6850000000000000000000000000000000000000000000000
-000000000000000000000000001f3f3f3f3f3f3f00000000000000000000000000000000
-00000000000000000000000000000000000000bfffffffffffffffffffffff7f00000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000dfffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9ed6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c80d000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000dadd6d6d6d6d6d6d6d6d6d6d68500000000000000000000
-00000000000000000000000000000000000000000000000f5fafefffffffffffffffffcf
-8f2f000000000000000000000000000000000000000000000000000000000000001fefff
-ffffffffffffffffff3f0000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000bfffffffffffffffffffffe69e9e9e9e9e9e
-9e9e9e9e9eacd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6ad00000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000000035c8d6d6d6d6d6d6d6d6d6
-d6d68500000000000000000000000000000000000000000000000000000000000000001f
-9fffffffffffffffffffffffffffffffbf3f000000000000000000000000000000000000
-0000000000000000000000007fffffffffffffffffffff0f000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000000000000000000000000009fffffff
-ffffffffffffffce9e9e9e9e9e9e9e9e9e9e9eacd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d68500000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00006bd6d6d6d6d6d6d6d6d6d6d6d6930000000000000000000000000000000000000000
-00000000000000000000000f8fffffffffffffffffffffffffffffffffffffff8f000000
-00000000000000000000000000000000000000000000000000000fefffffffffffffffff
-cf0000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000008fffffffffffffffffffffce9e9e9e9e9e9e9e9e9e9e9ebad6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000d93d6d6d6d6d6d6d6d6d6d6d6d6ad0d000000000000
-0000000000000000000000000000000000000000000000002fdfffffffffffffffffffff
-ffffffffffffffffffffff9f000000000000000000000000000000000000000000000000
-00000000008fffffffffffffffff9f000000000000000000000000000000000000000000
-00000000000000000000000000000000000000003f3f3f3f3f0f00000000000000000000
-000000000000000000000000000000000000000000000000bfffffffffffffffffffffce
-9e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d62800000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000000000000000028bbd6d6d6d6d6d6d6
-d6d6d6d6d6c81a0000000000000000000000000000000000000000000000000000000000
-005fefffffffffffffffffffffffffffffffffffffffffffffff3f000000000000000000
-000000000000000000000000000000000000002fffffffffffffffff5f00000000000000
-0000000000000000000000000000000000000000000000000000000000001f6fcfffffff
-ffffffffaf2f000000000000000000000000000000000000000000000000000000000000
-0000bfffffffffffffffffffffbc9e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c80d00000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000050d6d6d6d6d6d6d6d6d6d6d6d6d6d64200000000000000000000000000000000
-00000000000000000000000000005fffffffffffffffffffffffffffffffffffffffffff
-ffffffffaf0000000000000000000000000000000000000000000000000000000000efff
-ffffffffffff2f0000000000000000000000000000000000000000000000000000000000
-0000000000000f9fffffffffffffffffffffffef2f000000000000000000000000000000
-00000000000000000000000000000000cfffffffffffffffffffffb69e9e9e9e9e9e9e9e
-9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6ad0000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000d85d6d6d6d6d6d6d6d6d6d6d6d6d6d693000000
-0000000000000000000000000000000000000000000000000000002fefffffffffffffff
-ffffffffffffffffffffffffffffffffffffff0000000000000000000000000000000000
-000000000000000000000000bfffffffffffffff00000000000000000000000000000000
-000000000000000000000000000000000000004fefffffffffffffffffffffffffffaf00
-000000000000000000000000000000000000000000000000000000000000ffffffffffff
-ffffffffffb69e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6780000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000028add6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d61a00000000000000000000000000000000000000000000000000
-000000000fcfffffffffffffffffffffffffffffffffffffffffffffffffffffff1f0000
-00000000000000000000000000000000000000000000000000007fffffffffffffbf0000
-00000000000000000000000000000000000000000000000000000000000000008fffffff
-ffffffffffffffffffffffffff0000000000000000000000000000000000000000000000
-000000000000001fffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad1a000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000042c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d66b000000000000000000000000
-0000000000000000000000000000000000007fffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffff1f000000000000000000000000000000000000000000000000
-000000007fffffffffffff7f000000000000000000000000000000000000000000000000
-0000000000000000009fffffffffffffffffffffffffffffffffff000000000000000000
-0000000000000000000000000000000000000000003fffffffffffffffffffffffb69e9e
-9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d685000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000078d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d60d00000000000000000000000000000000000000000000000000000000001fffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffff0000000000000000000000
-0000000000000000000000000000000000004fffffffffffff4f00000000000000000000
-000000000000000000000000000000000000000000006fffffffffffffffffffffffffff
-ffffffffff0000000000000000000000000000000000000000000000000000000000007f
-ffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8500000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000001aadd6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d685000000000000000000000000000000000000000000
-0000000000000000009fffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffbf00000000000000000000000000000000000000000000000000000000003fffffff
-ffffff0f000000000000000000000000000000000000000000000000000000000000003f
-ffffffffffffffffffffffffffffffffffffcf0000000000000000000000000000000000
-00000000000000000000000000afffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e
-9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad2800
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000001ac8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d62800000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000007fffffffffffdf00000000000000000000000000000000000000
-0000000000000000000000000fdfffffffffffffffffffffffffffffffffffffaf000000
-000000000000000000000000000000000000000000000000000000cfffffffffffffffff
-ffffffb69e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6930d000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000a0d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6bb000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000007fffffffffffaf0000000000
-00000000000000000000000000000000000000000000000000007fffffffffffffffffff
-ffffffffffffffffffff7f00000000000000000000000000000000000000000000000000
-0000000000ffffffffffffffffffffffffbc9e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65d000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000dc8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d68500000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000afffffffffff6f000000000000000000000000000000000000000000000000000000
-0000000fefffffffffffffffffffffffffffffffffffffff3f0000000000000000000000
-0000000000000000000000000000000000003fffffffffffffffffffffffffce9e9e9e9e
-9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8
-280000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000028d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6500000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000cfffffffffff3f00000000000000000000000000
-00000000000000000000000000000000007fffffffffffffffffffffffffffffffffffff
-ffff0f00000000000000000000000000000000000000000000000000000000007fffffff
-ffffffffffffffffffce9e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6a00d00000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000005dd6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d635000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000ffffffffffff
-00000000000000000000000000000000000000000000000000000000000000dfffffffff
-ffffffffffffffffffffffffffffffdf0000000000000000000000000000000000000000
-00000000000000000000afffffffffffffffffffffffffce9e9e9e9e9e9e9e9e9e9e9eac
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d66b00000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000093d6d6d6d6d6d6d6d6d6d6d6d6d6d60000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000003fffffffffffbf00000000000000000000000000000000000000000000
-00000000000000004fffffffffffffffffffffffffffffffffffffffffaf000000000000
-000000000000000000000000000000000000000000000000dfffffffffffffffffffffff
-ffe69e9e9e9e9e9e9e9e9e9e9eacd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6c835000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000000dbbd6d6d6d6d6d6d6d6d6d6
-d6d6d6000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000006fffffffffff8f0000000000000000
-000000000000000000000000000000000000000000009fffffffffffffffffffffffffff
-ffffffffffffff7f00000000000000000000000000000000000000000000000000000000
-000fffffffffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9ed6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad1a0000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000028c8d6d6d6d6d6d6d6d6d6d6d6d600000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000000000000000000000000000af
-ffffffffff5f000000000000000000000000000000000000000000000000000000000000
-efffffffffffffffffffffffffffffffffffffffff3f0000000000000000000000000000
-0000000000000000000000000000004fffffffffffffffffffffffffffff9e9e9e9e9e9e
-9e9e9e9e9e9ed2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6780000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000050d6d6d6d6d6d6d6d6d6d6d6d60000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000dfffffffffff1f00000000000000000000000000000000
-000000000000000000000000002fffffffffffffffffffffffffffffffffffffffffff0f
-00000000000000000000000000000000000000000000000000000000007fffffffffffff
-ffffffffffffffffa49e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6c85000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000000000000000000000000000085d6d6
-d6d6d6d6d6d6d6d6d6000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000000000000001fffffffffffef000000
-0000000000000000000000000000000000000000000000000000006fffffffffffffffff
-ffffffffffffffffffffffffdf0000000000000000000000000000000000000000000000
-00000000000000bfffffffffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9ebad6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad28000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000dadd6d6d6d6d6d6d6d6d6d600000000000000000000000000
-0000000000000000000000000000000027737f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
-7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
-7f7f7f7f9fffffffffffaf00000000000000000000000000000000000000000000000000
-00000000009fffffffffffffffffffffffffffffffffffffffff9f000000000000000000
-000000000000000000000000000000000000000000efffffffffffffffffffffffffffff
-c89e9e9e9e9e9e9e9e9e9e9eafd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6850d0000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000028c8d6d6d6d6d6d6d6d6
-d60d000000000000000000000000000000000000000000000000000000003becffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffff7f0000000000000000000000
-00000000000000000000000000000000000000cfffffffffffffffffffffffffffffffff
-ffffffff6f00000000000000000000000000000000000000000000000000000000002fff
-ffffffffffffffffffffffffffffd49e9e9e9e9e9e9e9e9e9e9ea1d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d65d0000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000050d6d6d6d6d6d6d6d6d6350000000000000000000000000000000000000000
-00000000000000001dffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffff3f00000000000000000000000000000000000000000000000000000000000fffffff
-ffffffffffffffffffffffffffffffffffff3f0000000000000000000000000000000000
-0000000000000000000000005fffffffffffffffffffffffffffffffe69e9e9e9e9e9e9e
-9e9e9e9e9ecbd6d6d6d6d6d6d6d6d6d6d6d6bb2800000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000078d6d6d6d6d6d6d6d66b000000000000
-0000000000000000000000000000000000000000000000dfffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffff0f00000000000000000000000000000000000000
-000000000000000000003fffffffffffffffffffffffffffffffffffffffffff00000000
-00000000000000000000000000000000000000000000000000008fffffffffffffffffff
-ffffffffffffff9e9e9e9e9e9e9e9e9e9e9e9ebdd6d6d6d6d6d6d6d6d6d6d6a00d000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000000000000000000000000000ad
-d6d6d6d6d6d6d6a000000000000000000000000000000000000000000000000000000000
-006fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffcf000000000000
-0000000000000000000000000000000000000000000000007fffffffffffffffffffffff
-ffffffffffffffffffbf0000000000000000000000000000000000000000000000000000
-00000000cfffffffffffffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9eafd6d6
-d6d6d6d6d6d6d6d66b000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000001ac8d6d6d6d6d6d6d60d00000000000000000000000000
-0000000000000000000000000000000fdfffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffff9f00000000000000000000000000000000000000000000000000000000
-0000bfffffffffffffffffffffffffffffffffffffffff8f000000000000000000000000
-000000000000000000000000000000000000ffffffffffffffffffffffffffffffffffce
-9e9e9e9e9e9e9e9e9e9e9e9ed2d6d6d6d6d6d6d6c8350000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000000000000042d6d6d6d6d6d6d6
-6b00000000000000000000000000000000000000000000000000000000003fffffffffff
-ffffffffffffffffffffffffffffffffffffffcf3f3f3f3f5f7f7f7fafbfbfbfffffffff
-ffffffffffffffffffffffffffffffffffffffffff5f0000000000000000000000000000
-00000000000000000000000000000000efffffffffffffffffffffffffffffffffffffff
-ff5f00000000000000000000000000000000000000000000000000000000003fffffffff
-ffffffffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9ec1d6d6d6d6d6d6ad0d00
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000006bd6d6d6d6d6d6bb000000000000000000000000000000000000000000
-0000000000000000005fffffffffffffffffffffffffffffffffffffffffffffaf0f0000
-000000000000000000000000000f3f3f3f5f7f7f7fafbfbfbfffffffffffffffffffff2f
-00000000000000000000000000000000000000000000000000000000001fffffffffffff
-ffffffffffffffffffffffffffffff1f0000000000000000000000000000000000000000
-0000000000000000006fffffffffffffffffffffffffffffffffffffa49e9e9e9e9e9e9e
-9e9e9e9eafd6d6d6d6d67800000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000005d35000000000000000000000000000000
-00000000000000000000000000000000000000000000a0d6d6d6d6d6d65d000000000000
-0000000000000000000000000000000000000000000000004fefffffffffffffffffffff
-ffffffffffffffffdf4f0000000000000000000000000000000000000000000000000000
-00000000003fffffffffffffff0000000000000000000000000000000000000000000000
-000000000000005fffffffffffffffffffffffffffffffffffffffffef00000000000000
-0000000000000000000000000000000000000000000000afffffffffffffffffffffffff
-ffffffffffffbc9e9e9e9e9e9e9e9e9e9e9e9ed2d6d6c842000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000085d6c80d
-000000000000000000000000000000000000000000000000000000000000000000000000
-0dc8d6d6d6d6d6c80d000000000000000000000000000000000000000000000000000000
-0000000f7fefffffffffffffffffffffffffffffcf5f0000000000000000000000000000
-0000000000000000000000000000000000002fefffffffffffffbf000000000000000000
-0000000000000000000000000000000000000000008fffffffffffffffffffffffffffff
-ffffffffffffbf0000000000000000000000000000000000000000000000000000000000
-00dfffffffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e9ebdd6ad
-280000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000dadd6d6d69300000000000000000000000000000000000000000000
-00000000000000000000000000000035d6d6d6d6d6d69300000000000000000000000000
-000000000000000000000000000000000000000f4f8fbfffffffffffffffbf9f6f1f0000
-000000000000000000000000000000000000000000000000000000000000000fefffffff
-ffffffff7f000000000000000000000000000000000000000000000000000000000000cf
-ffffffffffffffffffffffffffffffffffffffff7f000000000000000000000000000000
-00000000000000000000000000000ffffffffffffffffffffffffffffffffffffffff89e
-9e9e9e9e9e9e9e9e9e9e9ea5850d00000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000028c8d6d6d6d6d64200000000000000
-0000000000000000000000000000000000000000000000000000000000005dd6d6d6d6d6
-d65d00000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000fcfffffffffffffffff4f0000000000000000000000000000000000
-00000000000000000000000000ffffffffffffffffffffffffffffffffffffffffff3f00
-000000000000000000000000000000000000000000000000000000004fffffffffffffff
-ffffffffffffffffffffffffffbc9e9e9e9e9e9e9e9e9e9e9e3b00000000000000000000
-0000000000000000000000000000000000000000000000000000000000000000000050d6
-d6d6d6d6d6d6c81a00000000000000000000000000000000000000000000000000000000
-00000000000000000093d6d6d6d6d6d65000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000002fdfffffffffffffffffff0f000000
-00000000000000000000000000000000000000000000000000003fffffffffffffffffff
-ffffffffffffffffffffffff0f0000000000000000000000000000000000000000000000
-0000000000007fffffffffffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e
-9e8a1d000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000078d6d6d6d6d6d6d6d6d6a00000000000000000000000000000
-00000000000000000000000000000000000000000000000dbbd6d6d6d6d6c82800000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000003fef
-ffffffffffffffffffdf0000000000000000000000000000000000000000000000000000
-000000006fffffffffffffffffffffffffffffffffffffffffdf00000000000000000000
-0000000000000000000000000000000000000000bfffffffffffffffffffffffffffffff
-ffffffffffffa49e9e9e9e9e9e9e6c090000000000000000000000000000000000000000
-00000000000000000000000000000000000000000000000da0d6d6d6d6d6d6d6d6d6d6d6
-5d0000000000000000000000000000000000000000000000000000000000000000000000
-000028d6d6d6d6d6d6c85000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000006fffffffffffffffffffffffaf000000000000000000000000
-000000000000000000000000000000000000afffffffffffffffffffffffffffffffffff
-ffffff9f000000000000000000000000000000000000000000000000000000000000efff
-ffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e450000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-28add6d6d6d6d6d6d6d6d6d6d6d6d6280000000000000000000000000000000000000000
-00000000000000000000000000000000005dd6d6d6d6d6d6d65d00000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000000000000000fbfffffffffffffffffffffff
-ff6f000000000000000000000000000000000000000000000000000000000000dfffffff
-ffffffffffffffffffffffffffffffffff6f000000000000000000000000000000000000
-00000000000000000000002ffffffffffffffffffffffffffffffffffffffffffffff29e
-9e9e9e942700000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000042c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad000000000000
-000000000000000000000000000000000000000000000000000000000000000085d6d6d6
-d6d6d6d6850d000000000000000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-6fefffffffffffffffffffffffffff3f0000000000000000000000000000000000000000
-0000000000000000001fffffffffffffffffffffffffffffffffffffffffff3f00000000
-000000000000000000000000000000000000000000000000005fffffffffffffffffffff
-ffffffffffffffffffffffffffb69e9e7609000000000000000000000000000000000000
-00000000000000000000000000000000000000000000000000006bd6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d678000000000000000000000000000000000000000000000000000000
-000000000000000000000dadd6d6d6d6d6d6d6bb35000000000000000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000003fcfffffffffffffffffffffffffffffff00000000000000
-00000000000000000000000000000000000000000000004fffffffffffffffffffffffff
-ffffffffffffffffff000000000000000000000000000000000000000000000000000000
-0000008fffffffffffffffffffffffffffffffffffffffffffffffe69e58000000000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-00000d85d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d635000000000000000000000000
-0000000000000000000000000000000000000000000000000028c8d6d6d6d6d6d6d6ac6c
-130000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000003fbfffffffffffffffffffff
-ffffffffffffbf0000000000000000000000000000000000000000000000000000000000
-007fffffffffffffffffffffffffffffffffffffffffbf00000000000000000000000000
-0000000000000000000000000000000000bfffffffffffffffffffffffffffffffffffff
-ffffffffffef310000000000000000000000000000000000000000000000000000000000
-0000000000000000000000000000001aadd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6bb0d000000000000000000000000000000000000000000000000000000000000000000
-0000000050d6d6d6d6d6d6c49e9e9e6c2700000000000000000000000000000000000000
-00000000000000000000000000000000000000000000000000000000000000000000000f
-6fdfffffffffffffffffffffffffffffffffffff8f000000000000000000000000000000
-000000000000000000000000000000bfffffffffffffffffffffffffffffffffffffffff
-8f000000000000000000000000000000000000000000000000000000000000ffffffffff
-ffffffffffffffffffffffffffffffffffffcf1f00000000000000000000000000000000
-0000000000000000000000000000000000000000000000000000000028c8d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d69300000000000000000000000000000000000000
-0000000000000000000000000000000000000085d6d6d6d6d2a59e9e9e9e9e8a45130000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000000000000000f5fafffffffffffffffffffffffffffffffffffffffffff5f00
-0000000000000000000000000000000000000000000000000000000000ffffffffffffff
-ffffffffffffffffffffffffffff5f000000000000000000000000000000000000000000
-00000000000000003fffffffffffffffffffffffffffffffffffffffffffff9f0f000000
-000000000000000000000000000000000000000000000000000000000000000000000000
-000000000050d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d64200000000
-00000000000000000000000000000000000000000000000000000000000000000000add6
-d6d6b69e9e9e9e9e9e9e9e9e805831090000000000000000000000000000000000000000
-00000000000000000000000000000000000000000f4f8fcfffffffffffffffffffffffff
-ffffffffffffffffffffffff1f0000000000000000000000000000000000000000000000
-0000000000002fffffffffffffffffffffffffffffffffffffffffff1f00000000000000
-000000000000000000000000000000000000000000006fffffffffffffffffffffffffff
-ffffffffffffffef5f000000000000000000000000000000000000000000000000000000
-00000000000000000000000000000000000085d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6c81a00000000000000000000000000000000000000000000000000
-0000000000000000000000001ac8d6c89e9e9e9e9e9e9e9e9e9e9e9e9eaacf9f7f3f1f00
-00000000000000000000000000000000000000000000000000000000002f3f7fafcfffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffef00000000000000000000
-00000000000000000000000000000000000000006fffffffffffffffffffffffffffffff
-ffffffffffef000000000000000000000000000000000000000000000000000000000000
-9fffffffffffffffffffffffffffffffffffffffdf2f0000000000000000000000000000
-0000000000000000000000000000000000000000000000000000000000000da0d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6a00000000000000000000000
-00000000000000000000000000000000000000000000000000000042d2a59e9e9e9e9e9e
-9e9e9e9e9e9e9edaffffffffffffcfbf9f7f7f6f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f
-7f7f7fafbfdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffdf7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7fbfff
-ffffffffffffffffffffffffffffffffffffffdf7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
-7f7f7f7f7f7f7f7f7f7f7f7f7f7fdfffffffffffffffffffffffffffffffffffffaf0f00
-000000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000028bbd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d65d0000000000000000000000000000000000000000000000000000000000000000
-0000000000005f9e9e9e9e9e9e9e9e9e9e9e9e9eb6ffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffff6f00000000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000050c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6280000000000000000000000000000000000
-000000000000000000000000000000000000000000809e9e9e9e9e9e9e9e9e9e9e9eecff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffef2f000000000000000000000000
-0000000000000000000000000000000000000000000000000000000000000000006bd6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad000000
-000000000000000000000000000000000000000000000000000000000000000000000009
-949e9e9e9e9e9e9e9e9e9ec8ffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbf
-0f0000000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000d93d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d678000000000000000000000000000000000000000000000000
-0000000000000000000000000000279e9e9e9e9e9e9e9e9ea4f8ffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffff7f0000000000000000000000000000000000000000000000
-000000000000000000000000000000000000000000001aadd6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d635000000000000000000
-00000000000000000000000000000000000000000000000000000000004f9e9e9e9e9e9e
-9e9ee0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffef4f00000000000000000000
-000000000000000000000000000000000000000000000000000000000000000000000035
-c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6bb0d000000000000000000000000000000000000000000000000000000000000
-0000000000000000769e9e9e9e9e9ec2ffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffcf1f000000000000000000000000000000000000000000000000000000000000000000
-0000000000000000000000005dd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d69300000000000000000000000000000000
-00000000000000000000000000000000000000000000098a9e9e9e9eaaf8ffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffff9f000000000000000000000000000000000000000000
-0000000000000000000000000000000000000000000000000085d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d64200
-000000000000000000000000000000000000000000000000000000000000000000000000
-001d9e9e9e9eecffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffdf7f7f7f7f7f7f7f7f
-7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f614f4f4f4f4f4f4f4f4f4f4f4f4f4f4f566b6b6b
-6b6badd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6c86b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b
-6b6b674f4f4f4f4f4f4f4f4f4f4f4f4f8a9e9ed4ffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeca49e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9eb3d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cba89e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec2ffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffe09e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eafd2d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a19e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9eb0f8ffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9ea8cbd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6bd9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4f8ffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1c4d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d2af9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4
-ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-b3d2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a59e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9ea4ecffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea5c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d2b69e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9edaffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb3d2d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a59e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9edaffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9ea1bad6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfac9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4daffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea5c1d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6cfb39e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4ecffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffc89e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9ea5c1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfb39e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9ea4ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-da9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1bacfd6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8af9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb0f8ffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffeca49e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9eafc1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6cfbaa59e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec2f8ffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff8b09e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1afc1d2d6d6d6d6d6d6d6d6d6d6d6d6d6
-d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cbbaa89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9ed4ffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffc89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9ea8b6c4cfd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8bdafa19e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaaecffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffe6aa9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1acb3bac4c8c8d6d6d6d6d6d6d6cfc8c8
-bdbaafa89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ebcf8ff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffff8c89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9ea4e0ffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffe6aa9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec2f8ffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-cea49e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb6e6
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffff8c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9eaadaffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff2c29e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaadaffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffff2c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaada
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffffffffffffffffffffff8ceaa9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9eb6e0ffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffe0bc9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaac8f2ffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffffffffffffffff8dabc9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaac8ecff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffff8e0c2aa9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9eb6d4ecffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffffffffffffffffffffffffffffffffffffff2e0c8b6a49e9e9e9e9e9e9e9e
-9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaabccee6ffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-fffffffffffff8e6d4cec2b6b6aa9e9e9e9e9e9e9e9eb6b6b6c8cee0e6ffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
-ffffffffffffffffffffffffffffffffffffffffffffff
-end
-%%PageTrailer
-%%Trailer
-%%EOF
--- /dev/null
+%!PS-Adobe-3.0 EPSF-3.0
+%%Creator: (ImageMagick)
+%%Title: (/homes/kaf24/xenlogo.eps)
+%%CreationDate: (Tue Oct 28 13:52:11 2003)
+%%BoundingBox: 155 324 445 461
+%%DocumentData: Clean7Bit
+%%LanguageLevel: 1
+%%Pages: 1
+%%EndComments
+
+%%BeginDefaults
+%%EndDefaults
+
+%%BeginProlog
+%
+% Display a color image. The image is displayed in color on
+% Postscript viewers or printers that support color, otherwise
+% it is displayed as grayscale.
+%
+/DirectClassPacket
+{
+ %
+ % Get a DirectClass packet.
+ %
+ % Parameters:
+ % red.
+ % green.
+ % blue.
+ % length: number of pixels minus one of this color (optional).
+ %
+ currentfile color_packet readhexstring pop pop
+ compression 0 eq
+ {
+ /number_pixels 3 def
+ }
+ {
+ currentfile byte readhexstring pop 0 get
+ /number_pixels exch 1 add 3 mul def
+ } ifelse
+ 0 3 number_pixels 1 sub
+ {
+ pixels exch color_packet putinterval
+ } for
+ pixels 0 number_pixels getinterval
+} bind def
+
+/DirectClassImage
+{
+ %
+ % Display a DirectClass image.
+ %
+ systemdict /colorimage known
+ {
+ columns rows 8
+ [
+ columns 0 0
+ rows neg 0 rows
+ ]
+ { DirectClassPacket } false 3 colorimage
+ }
+ {
+ %
+ % No colorimage operator; convert to grayscale.
+ %
+ columns rows 8
+ [
+ columns 0 0
+ rows neg 0 rows
+ ]
+ { GrayDirectClassPacket } image
+ } ifelse
+} bind def
+
+/GrayDirectClassPacket
+{
+ %
+ % Get a DirectClass packet; convert to grayscale.
+ %
+ % Parameters:
+ % red
+ % green
+ % blue
+ % length: number of pixels minus one of this color (optional).
+ %
+ currentfile color_packet readhexstring pop pop
+ color_packet 0 get 0.299 mul
+ color_packet 1 get 0.587 mul add
+ color_packet 2 get 0.114 mul add
+ cvi
+ /gray_packet exch def
+ compression 0 eq
+ {
+ /number_pixels 1 def
+ }
+ {
+ currentfile byte readhexstring pop 0 get
+ /number_pixels exch 1 add def
+ } ifelse
+ 0 1 number_pixels 1 sub
+ {
+ pixels exch gray_packet put
+ } for
+ pixels 0 number_pixels getinterval
+} bind def
+
+/GrayPseudoClassPacket
+{
+ %
+ % Get a PseudoClass packet; convert to grayscale.
+ %
+ % Parameters:
+ % index: index into the colormap.
+ % length: number of pixels minus one of this color (optional).
+ %
+ currentfile byte readhexstring pop 0 get
+ /offset exch 3 mul def
+ /color_packet colormap offset 3 getinterval def
+ color_packet 0 get 0.299 mul
+ color_packet 1 get 0.587 mul add
+ color_packet 2 get 0.114 mul add
+ cvi
+ /gray_packet exch def
+ compression 0 eq
+ {
+ /number_pixels 1 def
+ }
+ {
+ currentfile byte readhexstring pop 0 get
+ /number_pixels exch 1 add def
+ } ifelse
+ 0 1 number_pixels 1 sub
+ {
+ pixels exch gray_packet put
+ } for
+ pixels 0 number_pixels getinterval
+} bind def
+
+/PseudoClassPacket
+{
+ %
+ % Get a PseudoClass packet.
+ %
+ % Parameters:
+ % index: index into the colormap.
+ % length: number of pixels minus one of this color (optional).
+ %
+ currentfile byte readhexstring pop 0 get
+ /offset exch 3 mul def
+ /color_packet colormap offset 3 getinterval def
+ compression 0 eq
+ {
+ /number_pixels 3 def
+ }
+ {
+ currentfile byte readhexstring pop 0 get
+ /number_pixels exch 1 add 3 mul def
+ } ifelse
+ 0 3 number_pixels 1 sub
+ {
+ pixels exch color_packet putinterval
+ } for
+ pixels 0 number_pixels getinterval
+} bind def
+
+/PseudoClassImage
+{
+ %
+ % Display a PseudoClass image.
+ %
+ % Parameters:
+ % class: 0-PseudoClass or 1-Grayscale.
+ %
+ currentfile buffer readline pop
+ token pop /class exch def pop
+ class 0 gt
+ {
+ currentfile buffer readline pop
+ token pop /depth exch def pop
+ /grays columns 8 add depth sub depth mul 8 idiv string def
+ columns rows depth
+ [
+ columns 0 0
+ rows neg 0 rows
+ ]
+ { currentfile grays readhexstring pop } image
+ }
+ {
+ %
+ % Parameters:
+ % colors: number of colors in the colormap.
+ % colormap: red, green, blue color packets.
+ %
+ currentfile buffer readline pop
+ token pop /colors exch def pop
+ /colors colors 3 mul def
+ /colormap colors string def
+ currentfile colormap readhexstring pop pop
+ systemdict /colorimage known
+ {
+ columns rows 8
+ [
+ columns 0 0
+ rows neg 0 rows
+ ]
+ { PseudoClassPacket } false 3 colorimage
+ }
+ {
+ %
+ % No colorimage operator; convert to grayscale.
+ %
+ columns rows 8
+ [
+ columns 0 0
+ rows neg 0 rows
+ ]
+ { GrayPseudoClassPacket } image
+ } ifelse
+ } ifelse
+} bind def
+
+/DisplayImage
+{
+ %
+ % Display a DirectClass or PseudoClass image.
+ %
+ % Parameters:
+ % x & y translation.
+ % x & y scale.
+ % label pointsize.
+ % image label.
+ % image columns & rows.
+ % class: 0-DirectClass or 1-PseudoClass.
+ % compression: 0-none or 1-RunlengthEncoded.
+ % hex color packets.
+ %
+ gsave
+ /buffer 512 string def
+ /byte 1 string def
+ /color_packet 3 string def
+ /pixels 768 string def
+
+ currentfile buffer readline pop
+ token pop /x exch def
+ token pop /y exch def pop
+ x y translate
+ currentfile buffer readline pop
+ token pop /x exch def
+ token pop /y exch def pop
+ currentfile buffer readline pop
+ token pop /pointsize exch def pop
+ /Times-Roman findfont pointsize scalefont setfont
+ x y scale
+ currentfile buffer readline pop
+ token pop /columns exch def
+ token pop /rows exch def pop
+ currentfile buffer readline pop
+ token pop /class exch def pop
+ currentfile buffer readline pop
+ token pop /compression exch def pop
+ class 0 gt { PseudoClassImage } { DirectClassImage } ifelse
+ grestore
+} bind def
+%%EndProlog
+%%Page: 1 1
+%%PageBoundingBox: 155 324 445 461
+userdict begin
+DisplayImage
+155 324
+289.992 137.145
+12.000000
+302 143
+1
+1
+1
+8
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff8e6
+d4cec2b6b6aa9e9e9e9e9e9e9e9eb6b6b6c8cee0e6ffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffff2e0c8b6a49e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+aabccee6ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffff8e0c2aa9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb6ceecffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffff8dabc9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+aac8ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffe0bc9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaac8f2ffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff8ceaa9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb6e0
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff2c29e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9eaadaffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffff2c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaadaffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff8c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9eaadaffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffcea49e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb6e6ffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffe6aa9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9ec2f8ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffff8c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4e0ffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe6aa9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1acb6bac4c8c8d6d6d6d6d6d6
+d6cfc8c8bdbaafa89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9ebcf8ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffc89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea8b6c4
+cfd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8bdafa19e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaaecffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffff8b09e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9ea1afc1d2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6cbbaa89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ed4ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeca49e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eafc1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfbaa59e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9ec2f8ffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1bacfd6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6c8af9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb0f8ffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffc89e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9ea5c1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfb39e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9ea4ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea5c1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cf
+b39e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4ecffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1bdd6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfaf9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4
+daffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9eb3d2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a59e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9edaffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea5c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d2b69e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9edaffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb3d2d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a59e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9ea4ecffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9ea1c4d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d2af9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4ecffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffda9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea8cbd6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6bd9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9ea4f8ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffe09e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eafd2
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+c8a19e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb0f8ffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeca49e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9eb3d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cba89e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec2ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffff8b09e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec1d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d2a89e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9ed4ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9ec1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d2a89e9e9e9e9e9e9e9e9e9e9e9e9e9e9eecffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffda9e
+9e9e8027272727272727272727272b353535353535353535353535353535353535353535
+353535353535add6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c85035353535353535322727272727272727272727
+272727272d3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f5fefffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffff2a49e9e9e9e45000000000000000000000000000000000000
+00000000000000000000000000000000000000001ac8d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad28000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00003fefffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffb69e9e9e9e9e9e27000000
+000000000000000000000000000000000000000000000000000000000000000000000050
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6930d0000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000007fffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffd49e9e9e9e9e9e9e9413000000000000000000000000000000000000000000000000
+000000000000000000000000000085d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d66b0000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000000000fbfffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff8a49e9e9e9e9e9e9e9e8009000000000000000000
+000000000000000000000000000000000000000000000000000000000dadd6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c83500000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000002fdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e
+9e9e9e9e6200000000000000000000000000000000000000000000000000000000000000
+0000000000000028c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6ad1a000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000006fffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9e4500000000000000000000000000000000
+0000000000000000000000000000000000000000000050d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6850d0000000000000000000000000000
+00000000000000000000000000000000000000000000000000000000000fafffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9e9e9e2b00
+000000000000000000000000000000000000000000000000000000000000000000000000
+0085d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65d0000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000002fcfffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe09e9e
+9e9e9e9e9e9e9e9e9e9e9ea8c81a00000000000000000000000000000000000000000000
+0000000000000000000000000000000dadd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6c83500000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000005fefffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffaa9e9e9e9e9e9e9e9e9e9e9e9e9ecbd6ad0d00000000000000
+00000000000000000000000000000000000000000000000000000000000028d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad1a000000000000000000000000
+00000000000000000000000000000000000000000000000000000000000000009fffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e
+9e9ebad6d6d6850000000000000000000000000000000000000000000000000000000000
+0000000000000000005dd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d685
+0d0000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000001fcfffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffaa9e9e9e9e9e9e9e9e9e9e9e9ea5d6d6d6d6d65d0000000000000000000000000000
+00000000000000000000000000000000000000000000000093d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d65d0000000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000049efffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6
+350000000000000000000000000000000000000000000000000000000000000000000000
+00000dbbd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c83500000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000004faa
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffb69e9e9e9e9e9e
+9e9e9e9e9e9eacd6d6d6d6d6d6d6c81a0000000000000000000000000000000000000000
+000000000000000000000000000000000028d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6ad1a000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000009769e9ee0ffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffff29e9e9e9e9e9e9e9e9e9e9e9e9ecbd6d6d6d6d6d6d6d6ad0d0000000000
+00000000000000000000000000000000000000000000000000000000000000005dd6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6850d0000000000000000000000000000000000000000
+00000000000000000000000000000000000000000000001d949e9e9eb6ffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9eb3d6d6
+d6d6d6d6d6d6d6d685000000000000000000000000000000000000000000000000000000
+000000000000000000000093d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65d0000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+459e9e9e9e9e9ef2ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffa49e
+9e9e9e9e9e9e9e9e9e9e9ecfd6d6d6d6d6d6d6d6d6d6d65d000000000000000000000000
+000000000000000000000000000000000000000000000000000dbbd6d6d6d6d6d6d6d6d6
+d6d6d6c83500000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000096c9e9e9e9e9e9e9ec8ffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e9eacd6d6d6d6d6d6d6d6d6d6d6
+d6d635000000000000000000000000000000000000000000000000000000000000000000
+0000000035d6d6d6d6d6d6d6d6d6d6d6ad1a000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000001d8a9e9e9e9e9e9e9e9eaa
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffbc9e9e9e9e9e9e9e9e9e9e
+9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6c81a000000000000000000000000000000000000
+000000000000000000000000000000000000006bd6d6d6d6d6d6d6d6d6850d0000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00003b949e9e9e9e9e9e9e9e9e9ee0ffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffff89e9e9e9e9e9e9e9e9e9e9e9ea5d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad0d000000
+00000000000000000000000000000000000000000000000000000000000000000000a0d6
+d6d6d6d6d6d65d0000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000d7b9e9e9e9e9e9e9e9e9e9e9e9ec2ffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e9ebdd6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d68500000000000000000000000000000000000000000000000000
+0000000000000000000000000dc8d6d6d6d6c83500000000000000000000000000000000
+0000000000000000000000000000000000000000000000000000001aadd6a59e9e9e9e9e
+9e9e9e9e9e9ea4ffffffffffffffdfbf8f7f5f3f3f1f0000000000000000000000000000
+001f3f3f5f7f8fbfcfffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbc9e9e9e9e9e
+9e9e9e9e9e9e9ed2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65000000000000000000000
+00000000000000000000000000000000000000000000000000000035d6d6d6ad0d000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000042c8d6d6bd9e9e9e9e9e9e9e9e9e9e9e9ee6ffcf9f5f3f000000000000000000
+0000000000000000000000000000000000000000000000002f5f8fcfffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbf8f7f
+3f3f0f000000000000000000003f3f7f9fdfffffffffffffffffffffffffffffffffffff
+ffffffffffffffffa49e9e9e9e9e9e9e9e9e9e9eafd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d62800000000000000000000000000000000000000000000000000000000000000
+0000000000006bd685000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000078d6d6d6d6cf9e9e9e9e9e9e9e9e9e9e9e6c47
+1f0000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000f4f9fdfffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffbf3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3fefffffffffff
+ffffffffffffffaf6f2f000000000000000000000000000000000000000000001f6fcfff
+ffffffffffffffffffffffffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9ec1d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c80d00000000000000000000000000000000
+000000000000000000000000000000000000000000350000000000000000000000000000
+00000000000000000000000000000000000000000000000000000000000da0d6d6d6d6d6
+d6a89e9e9e9e9e9e9e763b09000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000004f9fffffffffffffffffffff
+ffffffffffffffffffffffffffffff6f0000000000000000000000000000000000000000
+000000000000001fffffffffffffffffffff9f4f00000000000000000000000000000000
+000000000000000000000000003fafffffffffffffffffffffffffffffffffffffffffce
+9e9e9e9e9e9e9e9e9e9e9e9ed2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad0000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000035c8d6d6d6d6d6d6d6bd9e9e9e9e94621300000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000f7fefffffffffffffffffffffffffffffffffffffffffffff3f000000000000
+0000000000000000000000000000000000000000004fffffffffffffffdf6f0f00000000
+00000000000000000000000000000000000000000000000000000000003fdfffffffffff
+ffffffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9eafd6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6850000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000005dd6d6d6d6d6d6d6d6d6cf9e9e944f0900
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000f8fffffffffffffffffffffffffffff
+ffffffffffffff000000000000000000000000000000000000000000000000000000008f
+ffffffffffdf5f0000000000000000000000000000000000000000000000000000000000
+00000000000000000f9fffffffffffffffffffffffffffffffffff9e9e9e9e9e9e9e9e9e
+9e9e9ebdd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6500000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000d93d6d6d6
+d6d6d6d6d6d6d6d69b4f0900000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+2fcfffffffffffffffffffffffffffffffffffffbf000000000000000000000000000000
+00000000000000000000000000bfffffffef5f0000000000000000000000000000000000
+0000000000000000000000000000000000000000000000009fffffffffffffffffffffff
+ffffffffe69e9e9e9e9e9e9e9e9e9e9e9ecbd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6280000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000028bbd6d6d6d6d6d6d6d6d6d6d6850d00000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000f9fffffffffffffffffffffffffffffffffff8f00
+000000000000000000000000000000000000000000000000000000ffffff8f0f00000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000009fffffffffffffffffffffffffffffd49e9e9e9e9e9e9e9e9e9e9ea1d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c80d0000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000050c8d6d6d6d6d6d6d6d6d6d6ad3500
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000006fffffffff
+ffffffffffffffffffffffff5f0000000000000000000000000000000000000000000000
+000000003fffef3f00000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000bfffffffffffffffffffffffffffc89e9e9e
+9e9e9e9e9e9e9e9eafd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000000000000000000000d85d6
+d6d6d6d6d6d6d6d6d6d66b00000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000005fffffffffffffffffffffffffffffff1f000000000000000000
+0000000000000000000000000000000000006fbf0f000000000000000000000000000000
+00000000000000000000000000000000000000000000000000000000000000001fffffff
+ffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d685000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000028add6d6d6d6d6d6d6d6d6d6c835000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000005fffffffffffffffffffff
+ffffffef000000000000000000000000000000000000000000000000000000003f000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000009fffffffffffffffffffffffffa49e9e9e9e9e9e9e9e9e9e9e
+c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d650000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000042c8d6d6d6d6d6d6d6d6d6d6ad
+0d0000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000007fffffffffffffffffffffffffaf000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000002fffffffffffffffffffff
+ffff9e9e9e9e9e9e9e9e9e9e9e9ed2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d628000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+78d6d6d6d6d6d6d6d6d6d6d6850000000000000000000000000000000000000000000000
+000000000000000000000000001f3f3f3f3f3f3f00000000000000000000000000000000
+00000000000000000000000000000000000000bfffffffffffffffffffffff7f00000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000dfffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9ed6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c80d000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000dadd6d6d6d6d6d6d6d6d6d6d68500000000000000000000
+00000000000000000000000000000000000000000000000f5fafefffffffffffffffffcf
+8f2f000000000000000000000000000000000000000000000000000000000000001fefff
+ffffffffffffffffff3f0000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000bfffffffffffffffffffffe69e9e9e9e9e9e
+9e9e9e9e9eacd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6ad00000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000035c8d6d6d6d6d6d6d6d6d6
+d6d68500000000000000000000000000000000000000000000000000000000000000001f
+9fffffffffffffffffffffffffffffffbf3f000000000000000000000000000000000000
+0000000000000000000000007fffffffffffffffffffff0f000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000000000000000000000000009fffffff
+ffffffffffffffce9e9e9e9e9e9e9e9e9e9e9eacd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d68500000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00006bd6d6d6d6d6d6d6d6d6d6d6d6930000000000000000000000000000000000000000
+00000000000000000000000f8fffffffffffffffffffffffffffffffffffffff8f000000
+00000000000000000000000000000000000000000000000000000fefffffffffffffffff
+cf0000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000008fffffffffffffffffffffce9e9e9e9e9e9e9e9e9e9e9ebad6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000d93d6d6d6d6d6d6d6d6d6d6d6d6ad0d000000000000
+0000000000000000000000000000000000000000000000002fdfffffffffffffffffffff
+ffffffffffffffffffffff9f000000000000000000000000000000000000000000000000
+00000000008fffffffffffffffff9f000000000000000000000000000000000000000000
+00000000000000000000000000000000000000003f3f3f3f3f0f00000000000000000000
+000000000000000000000000000000000000000000000000bfffffffffffffffffffffce
+9e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d62800000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000000000000000028bbd6d6d6d6d6d6d6
+d6d6d6d6d6c81a0000000000000000000000000000000000000000000000000000000000
+005fefffffffffffffffffffffffffffffffffffffffffffffff3f000000000000000000
+000000000000000000000000000000000000002fffffffffffffffff5f00000000000000
+0000000000000000000000000000000000000000000000000000000000001f6fcfffffff
+ffffffffaf2f000000000000000000000000000000000000000000000000000000000000
+0000bfffffffffffffffffffffbc9e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c80d00000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000050d6d6d6d6d6d6d6d6d6d6d6d6d6d64200000000000000000000000000000000
+00000000000000000000000000005fffffffffffffffffffffffffffffffffffffffffff
+ffffffffaf0000000000000000000000000000000000000000000000000000000000efff
+ffffffffffff2f0000000000000000000000000000000000000000000000000000000000
+0000000000000f9fffffffffffffffffffffffef2f000000000000000000000000000000
+00000000000000000000000000000000cfffffffffffffffffffffb69e9e9e9e9e9e9e9e
+9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6ad0000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000d85d6d6d6d6d6d6d6d6d6d6d6d6d6d693000000
+0000000000000000000000000000000000000000000000000000002fefffffffffffffff
+ffffffffffffffffffffffffffffffffffffff0000000000000000000000000000000000
+000000000000000000000000bfffffffffffffff00000000000000000000000000000000
+000000000000000000000000000000000000004fefffffffffffffffffffffffffffaf00
+000000000000000000000000000000000000000000000000000000000000ffffffffffff
+ffffffffffb69e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6780000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000028add6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d61a00000000000000000000000000000000000000000000000000
+000000000fcfffffffffffffffffffffffffffffffffffffffffffffffffffffff1f0000
+00000000000000000000000000000000000000000000000000007fffffffffffffbf0000
+00000000000000000000000000000000000000000000000000000000000000008fffffff
+ffffffffffffffffffffffffff0000000000000000000000000000000000000000000000
+000000000000001fffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad1a000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000042c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d66b000000000000000000000000
+0000000000000000000000000000000000007fffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffff1f000000000000000000000000000000000000000000000000
+000000007fffffffffffff7f000000000000000000000000000000000000000000000000
+0000000000000000009fffffffffffffffffffffffffffffffffff000000000000000000
+0000000000000000000000000000000000000000003fffffffffffffffffffffffb69e9e
+9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d685000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000078d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d60d00000000000000000000000000000000000000000000000000000000001fffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffff0000000000000000000000
+0000000000000000000000000000000000004fffffffffffff4f00000000000000000000
+000000000000000000000000000000000000000000006fffffffffffffffffffffffffff
+ffffffffff0000000000000000000000000000000000000000000000000000000000007f
+ffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8500000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000001aadd6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d685000000000000000000000000000000000000000000
+0000000000000000009fffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffbf00000000000000000000000000000000000000000000000000000000003fffffff
+ffffff0f000000000000000000000000000000000000000000000000000000000000003f
+ffffffffffffffffffffffffffffffffffffcf0000000000000000000000000000000000
+00000000000000000000000000afffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e
+9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad2800
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000001ac8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d62800000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000007fffffffffffdf00000000000000000000000000000000000000
+0000000000000000000000000fdfffffffffffffffffffffffffffffffffffffaf000000
+000000000000000000000000000000000000000000000000000000cfffffffffffffffff
+ffffffb69e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6930d000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000a0d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6bb000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000007fffffffffffaf0000000000
+00000000000000000000000000000000000000000000000000007fffffffffffffffffff
+ffffffffffffffffffff7f00000000000000000000000000000000000000000000000000
+0000000000ffffffffffffffffffffffffbc9e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d65d000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000dc8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d68500000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000afffffffffff6f000000000000000000000000000000000000000000000000000000
+0000000fefffffffffffffffffffffffffffffffffffffff3f0000000000000000000000
+0000000000000000000000000000000000003fffffffffffffffffffffffffce9e9e9e9e
+9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8
+280000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000028d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6500000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000cfffffffffff3f00000000000000000000000000
+00000000000000000000000000000000007fffffffffffffffffffffffffffffffffffff
+ffff0f00000000000000000000000000000000000000000000000000000000007fffffff
+ffffffffffffffffffce9e9e9e9e9e9e9e9e9e9e9ebad6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6a00d00000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000005dd6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d635000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000ffffffffffff
+00000000000000000000000000000000000000000000000000000000000000dfffffffff
+ffffffffffffffffffffffffffffffdf0000000000000000000000000000000000000000
+00000000000000000000afffffffffffffffffffffffffce9e9e9e9e9e9e9e9e9e9e9eac
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d66b00000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000093d6d6d6d6d6d6d6d6d6d6d6d6d6d60000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000003fffffffffffbf00000000000000000000000000000000000000000000
+00000000000000004fffffffffffffffffffffffffffffffffffffffffaf000000000000
+000000000000000000000000000000000000000000000000dfffffffffffffffffffffff
+ffe69e9e9e9e9e9e9e9e9e9e9eacd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6c835000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000dbbd6d6d6d6d6d6d6d6d6d6
+d6d6d6000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000006fffffffffff8f0000000000000000
+000000000000000000000000000000000000000000009fffffffffffffffffffffffffff
+ffffffffffffff7f00000000000000000000000000000000000000000000000000000000
+000fffffffffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9ed6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad1a0000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000028c8d6d6d6d6d6d6d6d6d6d6d6d600000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000000000000000000000000af
+ffffffffff5f000000000000000000000000000000000000000000000000000000000000
+efffffffffffffffffffffffffffffffffffffffff3f0000000000000000000000000000
+0000000000000000000000000000004fffffffffffffffffffffffffffff9e9e9e9e9e9e
+9e9e9e9e9e9ed2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6780000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000050d6d6d6d6d6d6d6d6d6d6d6d60000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000dfffffffffff1f00000000000000000000000000000000
+000000000000000000000000002fffffffffffffffffffffffffffffffffffffffffff0f
+00000000000000000000000000000000000000000000000000000000007fffffffffffff
+ffffffffffffffffa49e9e9e9e9e9e9e9e9e9e9ec8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6c85000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000000000000000000000000000085d6d6
+d6d6d6d6d6d6d6d6d6000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000000000000001fffffffffffef000000
+0000000000000000000000000000000000000000000000000000006fffffffffffffffff
+ffffffffffffffffffffffffdf0000000000000000000000000000000000000000000000
+00000000000000bfffffffffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9ebad6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad28000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000dadd6d6d6d6d6d6d6d6d6d600000000000000000000000000
+0000000000000000000000000000000027737f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
+7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
+7f7f7f7f9fffffffffffaf00000000000000000000000000000000000000000000000000
+00000000009fffffffffffffffffffffffffffffffffffffffff9f000000000000000000
+000000000000000000000000000000000000000000efffffffffffffffffffffffffffff
+c89e9e9e9e9e9e9e9e9e9e9eafd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6850d0000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000028c8d6d6d6d6d6d6d6d6
+d60d000000000000000000000000000000000000000000000000000000003becffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff7f0000000000000000000000
+00000000000000000000000000000000000000cfffffffffffffffffffffffffffffffff
+ffffffff6f00000000000000000000000000000000000000000000000000000000002fff
+ffffffffffffffffffffffffffffd49e9e9e9e9e9e9e9e9e9e9ea1d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d65d0000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000050d6d6d6d6d6d6d6d6d6350000000000000000000000000000000000000000
+00000000000000001dffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffff3f00000000000000000000000000000000000000000000000000000000000fffffff
+ffffffffffffffffffffffffffffffffffff3f0000000000000000000000000000000000
+0000000000000000000000005fffffffffffffffffffffffffffffffe69e9e9e9e9e9e9e
+9e9e9e9e9ecbd6d6d6d6d6d6d6d6d6d6d6d6bb2800000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000078d6d6d6d6d6d6d6d66b000000000000
+0000000000000000000000000000000000000000000000dfffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffff0f00000000000000000000000000000000000000
+000000000000000000003fffffffffffffffffffffffffffffffffffffffffff00000000
+00000000000000000000000000000000000000000000000000008fffffffffffffffffff
+ffffffffffffff9e9e9e9e9e9e9e9e9e9e9e9ebdd6d6d6d6d6d6d6d6d6d6d6a00d000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000000000000000000000000ad
+d6d6d6d6d6d6d6a000000000000000000000000000000000000000000000000000000000
+006fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffcf000000000000
+0000000000000000000000000000000000000000000000007fffffffffffffffffffffff
+ffffffffffffffffffbf0000000000000000000000000000000000000000000000000000
+00000000cfffffffffffffffffffffffffffffffffb69e9e9e9e9e9e9e9e9e9e9eafd6d6
+d6d6d6d6d6d6d6d66b000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000001ac8d6d6d6d6d6d6d60d00000000000000000000000000
+0000000000000000000000000000000fdfffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffff9f00000000000000000000000000000000000000000000000000000000
+0000bfffffffffffffffffffffffffffffffffffffffff8f000000000000000000000000
+000000000000000000000000000000000000ffffffffffffffffffffffffffffffffffce
+9e9e9e9e9e9e9e9e9e9e9e9ed2d6d6d6d6d6d6d6c8350000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000000000042d6d6d6d6d6d6d6
+6b00000000000000000000000000000000000000000000000000000000003fffffffffff
+ffffffffffffffffffffffffffffffffffffffcf3f3f3f3f5f7f7f7fafbfbfbfffffffff
+ffffffffffffffffffffffffffffffffffffffffff5f0000000000000000000000000000
+00000000000000000000000000000000efffffffffffffffffffffffffffffffffffffff
+ff5f00000000000000000000000000000000000000000000000000000000003fffffffff
+ffffffffffffffffffffffffffe69e9e9e9e9e9e9e9e9e9e9e9ec1d6d6d6d6d6d6ad0d00
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000006bd6d6d6d6d6d6bb000000000000000000000000000000000000000000
+0000000000000000005fffffffffffffffffffffffffffffffffffffffffffffaf0f0000
+000000000000000000000000000f3f3f3f5f7f7f7fafbfbfbfffffffffffffffffffff2f
+00000000000000000000000000000000000000000000000000000000001fffffffffffff
+ffffffffffffffffffffffffffffff1f0000000000000000000000000000000000000000
+0000000000000000006fffffffffffffffffffffffffffffffffffffa49e9e9e9e9e9e9e
+9e9e9e9eafd6d6d6d6d67800000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000005d35000000000000000000000000000000
+00000000000000000000000000000000000000000000a0d6d6d6d6d6d65d000000000000
+0000000000000000000000000000000000000000000000004fefffffffffffffffffffff
+ffffffffffffffffdf4f0000000000000000000000000000000000000000000000000000
+00000000003fffffffffffffff0000000000000000000000000000000000000000000000
+000000000000005fffffffffffffffffffffffffffffffffffffffffef00000000000000
+0000000000000000000000000000000000000000000000afffffffffffffffffffffffff
+ffffffffffffbc9e9e9e9e9e9e9e9e9e9e9e9ed2d6d6c842000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000085d6c80d
+000000000000000000000000000000000000000000000000000000000000000000000000
+0dc8d6d6d6d6d6c80d000000000000000000000000000000000000000000000000000000
+0000000f7fefffffffffffffffffffffffffffffcf5f0000000000000000000000000000
+0000000000000000000000000000000000002fefffffffffffffbf000000000000000000
+0000000000000000000000000000000000000000008fffffffffffffffffffffffffffff
+ffffffffffffbf0000000000000000000000000000000000000000000000000000000000
+00dfffffffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e9ebdd6ad
+280000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000dadd6d6d69300000000000000000000000000000000000000000000
+00000000000000000000000000000035d6d6d6d6d6d69300000000000000000000000000
+000000000000000000000000000000000000000f4f8fbfffffffffffffffbf9f6f1f0000
+000000000000000000000000000000000000000000000000000000000000000fefffffff
+ffffffff7f000000000000000000000000000000000000000000000000000000000000cf
+ffffffffffffffffffffffffffffffffffffffff7f000000000000000000000000000000
+00000000000000000000000000000ffffffffffffffffffffffffffffffffffffffff89e
+9e9e9e9e9e9e9e9e9e9e9ea5850d00000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000028c8d6d6d6d6d64200000000000000
+0000000000000000000000000000000000000000000000000000000000005dd6d6d6d6d6
+d65d00000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000fcfffffffffffffffff4f0000000000000000000000000000000000
+00000000000000000000000000ffffffffffffffffffffffffffffffffffffffffff3f00
+000000000000000000000000000000000000000000000000000000004fffffffffffffff
+ffffffffffffffffffffffffffbc9e9e9e9e9e9e9e9e9e9e9e3b00000000000000000000
+0000000000000000000000000000000000000000000000000000000000000000000050d6
+d6d6d6d6d6d6c81a00000000000000000000000000000000000000000000000000000000
+00000000000000000093d6d6d6d6d6d65000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000002fdfffffffffffffffffff0f000000
+00000000000000000000000000000000000000000000000000003fffffffffffffffffff
+ffffffffffffffffffffffff0f0000000000000000000000000000000000000000000000
+0000000000007fffffffffffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e
+9e8a1d000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000078d6d6d6d6d6d6d6d6d6a00000000000000000000000000000
+00000000000000000000000000000000000000000000000dbbd6d6d6d6d6c82800000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000003fef
+ffffffffffffffffffdf0000000000000000000000000000000000000000000000000000
+000000006fffffffffffffffffffffffffffffffffffffffffdf00000000000000000000
+0000000000000000000000000000000000000000bfffffffffffffffffffffffffffffff
+ffffffffffffa49e9e9e9e9e9e9e6c090000000000000000000000000000000000000000
+00000000000000000000000000000000000000000000000da0d6d6d6d6d6d6d6d6d6d6d6
+5d0000000000000000000000000000000000000000000000000000000000000000000000
+000028d6d6d6d6d6d6c85000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000006fffffffffffffffffffffffaf000000000000000000000000
+000000000000000000000000000000000000afffffffffffffffffffffffffffffffffff
+ffffff9f000000000000000000000000000000000000000000000000000000000000efff
+ffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e450000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+28add6d6d6d6d6d6d6d6d6d6d6d6d6280000000000000000000000000000000000000000
+00000000000000000000000000000000005dd6d6d6d6d6d6d65d00000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000000000000000fbfffffffffffffffffffffff
+ff6f000000000000000000000000000000000000000000000000000000000000dfffffff
+ffffffffffffffffffffffffffffffffff6f000000000000000000000000000000000000
+00000000000000000000002ffffffffffffffffffffffffffffffffffffffffffffff29e
+9e9e9e942700000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000042c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad000000000000
+000000000000000000000000000000000000000000000000000000000000000085d6d6d6
+d6d6d6d6850d000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+6fefffffffffffffffffffffffffff3f0000000000000000000000000000000000000000
+0000000000000000001fffffffffffffffffffffffffffffffffffffffffff3f00000000
+000000000000000000000000000000000000000000000000005fffffffffffffffffffff
+ffffffffffffffffffffffffffb69e9e7609000000000000000000000000000000000000
+00000000000000000000000000000000000000000000000000006bd6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d678000000000000000000000000000000000000000000000000000000
+000000000000000000000dadd6d6d6d6d6d6d6bb35000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000003fcfffffffffffffffffffffffffffffff00000000000000
+00000000000000000000000000000000000000000000004fffffffffffffffffffffffff
+ffffffffffffffffff000000000000000000000000000000000000000000000000000000
+0000008fffffffffffffffffffffffffffffffffffffffffffffffe69e58000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+00000d85d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d635000000000000000000000000
+0000000000000000000000000000000000000000000000000028c8d6d6d6d6d6d6d6ac6c
+130000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000003fbfffffffffffffffffffff
+ffffffffffffbf0000000000000000000000000000000000000000000000000000000000
+007fffffffffffffffffffffffffffffffffffffffffbf00000000000000000000000000
+0000000000000000000000000000000000bfffffffffffffffffffffffffffffffffffff
+ffffffffffef310000000000000000000000000000000000000000000000000000000000
+0000000000000000000000000000001aadd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6bb0d000000000000000000000000000000000000000000000000000000000000000000
+0000000050d6d6d6d6d6d6c49e9e9e6c2700000000000000000000000000000000000000
+00000000000000000000000000000000000000000000000000000000000000000000000f
+6fdfffffffffffffffffffffffffffffffffffff8f000000000000000000000000000000
+000000000000000000000000000000bfffffffffffffffffffffffffffffffffffffffff
+8f000000000000000000000000000000000000000000000000000000000000ffffffffff
+ffffffffffffffffffffffffffffffffffffcf1f00000000000000000000000000000000
+0000000000000000000000000000000000000000000000000000000028c8d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d69300000000000000000000000000000000000000
+0000000000000000000000000000000000000085d6d6d6d6d2a59e9e9e9e9e8a45130000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000f5fafffffffffffffffffffffffffffffffffffffffffff5f00
+0000000000000000000000000000000000000000000000000000000000ffffffffffffff
+ffffffffffffffffffffffffffff5f000000000000000000000000000000000000000000
+00000000000000003fffffffffffffffffffffffffffffffffffffffffffff9f0f000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+000000000050d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d64200000000
+00000000000000000000000000000000000000000000000000000000000000000000add6
+d6d6b69e9e9e9e9e9e9e9e9e805831090000000000000000000000000000000000000000
+00000000000000000000000000000000000000000f4f8fcfffffffffffffffffffffffff
+ffffffffffffffffffffffff1f0000000000000000000000000000000000000000000000
+0000000000002fffffffffffffffffffffffffffffffffffffffffff1f00000000000000
+000000000000000000000000000000000000000000006fffffffffffffffffffffffffff
+ffffffffffffffef5f000000000000000000000000000000000000000000000000000000
+00000000000000000000000000000000000085d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6c81a00000000000000000000000000000000000000000000000000
+0000000000000000000000001ac8d6c89e9e9e9e9e9e9e9e9e9e9e9e9eaacf9f7f3f1f00
+00000000000000000000000000000000000000000000000000000000002f3f7fafcfffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffef00000000000000000000
+00000000000000000000000000000000000000006fffffffffffffffffffffffffffffff
+ffffffffffef000000000000000000000000000000000000000000000000000000000000
+9fffffffffffffffffffffffffffffffffffffffdf2f0000000000000000000000000000
+0000000000000000000000000000000000000000000000000000000000000da0d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6a00000000000000000000000
+00000000000000000000000000000000000000000000000000000042d2a59e9e9e9e9e9e
+9e9e9e9e9e9e9edaffffffffffffcfbf9f7f7f6f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f3f
+7f7f7fafbfdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffdf7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7fbfff
+ffffffffffffffffffffffffffffffffffffffdf7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
+7f7f7f7f7f7f7f7f7f7f7f7f7f7fdfffffffffffffffffffffffffffffffffffffaf0f00
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000028bbd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d65d0000000000000000000000000000000000000000000000000000000000000000
+0000000000005f9e9e9e9e9e9e9e9e9e9e9e9e9eb6ffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffff6f00000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000050c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6280000000000000000000000000000000000
+000000000000000000000000000000000000000000809e9e9e9e9e9e9e9e9e9e9e9eecff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffef2f000000000000000000000000
+0000000000000000000000000000000000000000000000000000000000000000006bd6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6ad000000
+000000000000000000000000000000000000000000000000000000000000000000000009
+949e9e9e9e9e9e9e9e9e9ec8ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbf
+0f0000000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000d93d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d678000000000000000000000000000000000000000000000000
+0000000000000000000000000000279e9e9e9e9e9e9e9e9ea4f8ffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffff7f0000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000001aadd6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d635000000000000000000
+00000000000000000000000000000000000000000000000000000000004f9e9e9e9e9e9e
+9e9ee0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffef4f00000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000035
+c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6bb0d000000000000000000000000000000000000000000000000000000000000
+0000000000000000769e9e9e9e9e9ec2ffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffcf1f000000000000000000000000000000000000000000000000000000000000000000
+0000000000000000000000005dd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d69300000000000000000000000000000000
+00000000000000000000000000000000000000000000098a9e9e9e9eaaf8ffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffff9f000000000000000000000000000000000000000000
+0000000000000000000000000000000000000000000000000085d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d64200
+000000000000000000000000000000000000000000000000000000000000000000000000
+001d9e9e9e9eecffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffdf7f7f7f7f7f7f7f7f
+7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f614f4f4f4f4f4f4f4f4f4f4f4f4f4f4f566b6b6b
+6b6badd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6c86b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b6b
+6b6b674f4f4f4f4f4f4f4f4f4f4f4f4f8a9e9ed4ffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeca49e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9eb3d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cba89e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec2ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffe09e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eafd2d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a19e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9eb0f8ffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffda9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9ea8cbd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6bd9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4f8ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1c4d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d2af9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4
+ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+b3d2d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a59e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9ea4ecffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea5c8d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d2b69e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9edaffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb3d2d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8a59e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9edaffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffc29e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9ea1bad6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfac9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4daffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffc29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea5c1d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6cfb39e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea4ecffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffc89e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9ea5c1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cfb39e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9ea4ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+da9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1bacfd6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8af9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb0f8ffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffeca49e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9eafc1d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6cfbaa59e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec2f8ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff8b09e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1afc1d2d6d6d6d6d6d6d6d6d6d6d6d6d6
+d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6cbbaa89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9ed4ffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffc89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9ea8b6c4cfd6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6d6c8bdafa19e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaaecffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffe6aa9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ea1acb3bac4c8c8d6d6d6d6d6d6d6cfc8c8
+bdbaafa89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ebcf8ff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffff8c89e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9ea4e0ffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffe6aa9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9ec2f8ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+cea49e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eb6e6
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff8c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9eaadaffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff2c29e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaadaffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffff2c29e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaada
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff8ceaa9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9eb6e0ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffe0bc9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaac8f2ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff8dabc9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaac8ecff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffff8e0c2aa9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9eb6d4ecffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffff2e0c8b6a49e9e9e9e9e9e9e9e
+9e9e9e9e9e9e9e9e9e9e9e9e9e9e9e9eaabccee6ffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffff8e6d4cec2b6b6aa9e9e9e9e9e9e9e9eb6b6b6c8cee0e6ffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffff
+end
+%%PageTrailer
+%%Trailer
+%%EOF
+++ /dev/null
-\documentclass[11pt,twoside,final,openright]{xenstyle}
-\usepackage{a4,graphicx,setspace}
-\setstretch{1.15}
-\input{style.tex}
-
-\begin{document}
-
-% TITLE PAGE
-\pagestyle{empty}
-\begin{center}
-\vspace*{\fill}
-\includegraphics{eps/xenlogo.eps}
-\vfill
-\vfill
-\vfill
-\begin{tabular}{l}
-{\Huge \bf Interface manual} \\[4mm]
-{\huge Xen v2.0 for x86} \\[80mm]
-
-{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
-{\Large University of Cambridge, UK} \\[20mm]
-{\large Last updated on 11th March, 2004}
-\end{tabular}
-\vfill
-\end{center}
-\cleardoublepage
-
-% TABLE OF CONTENTS
-\pagestyle{plain}
-\pagenumbering{roman}
-{ \parskip 0pt plus 1pt
- \tableofcontents }
-\cleardoublepage
-
-% PREPARE FOR MAIN TEXT
-\pagenumbering{arabic}
-\raggedbottom
-\widowpenalty=10000
-\clubpenalty=10000
-\parindent=0pt
-\renewcommand{\topfraction}{.8}
-\renewcommand{\bottomfraction}{.8}
-\renewcommand{\textfraction}{.2}
-\renewcommand{\floatpagefraction}{.8}
-\setstretch{1.15}
-
-\chapter{Introduction}
-Xen allows the hardware resouces of a machine to be virtualized and
-dynamically partitioned such as to allow multiple different 'guest'
-operating system images to be run simultaneously.
-
-Virtualizing the machine in this manner provides flexibility allowing
-different users to choose their preferred operating system (Windows,
-Linux, NetBSD, or a custom operating system). Furthermore, Xen provides
-secure partitioning between these 'domains', and enables better resource
-accounting and QoS isolation than can be achieved with a conventional
-operating system.
-
-The hypervisor runs directly on server hardware and dynamically partitions
-it between a number of {\it domains}, each of which hosts an instance
-of a {\it guest operating system}. The hypervisor provides just enough
-abstraction of the machine to allow effective isolation and resource
-management between these domains.
-
-Xen essentially takes a virtual machine approach as pioneered by IBM
-VM/370. However, unlike VM/370 or more recent efforts such as VMWare
-and Virtual PC, Xen doesn not attempt to completely virtualize the
-underlying hardware. Instead parts of the hosted guest operating
-systems are modified to work with the hypervisor; the operating system
-is effectively ported to a new target architecture, typically
-requiring changes in just the machine-dependent code. The user-level
-API is unchanged, thus existing binaries and operating system
-distributions can work unmodified.
-
-In addition to exporting virtualized instances of CPU, memory, network and
-block devicees, Xen exposes a control interface to set how these resources
-are shared between the running domains. The control interface is privileged
-and may only be accessed by one particular virtual machine: {\it domain0}.
-This domain is a required part of any Xen-base server and runs the application
-software that manages the control-plane aspects of the platform. Running the
-control software in {\it domain0}, distinct from the hypervisor itself, allows
-the Xen framework to separate the notions of {\it mechanism} and {\it policy}
-within the system.
-
-
-\chapter{CPU state}
-
-All privileged state must be handled by Xen. The guest OS has no
-direct access to CR3 and is not permitted to update privileged bits in
-EFLAGS.
-
-\chapter{Exceptions}
-The IDT is virtualised by submitting a virtual 'trap
-table' to Xen. Most trap handlers are identical to native x86
-handlers. The page-fault handler is a noteable exception.
-
-\chapter{Interrupts and events}
-Interrupts are virtualized by mapping them to events, which are delivered
-asynchronously to the target domain. A guest OS can map these events onto
-its standard interrupt dispatch mechanisms, such as a simple vectoring
-scheme. Each physical interrupt source controlled by the hypervisor, including
-network devices, disks, or the timer subsystem, is responsible for identifying
-the target for an incoming interrupt and sending an event to that domain.
-
-This demultiplexing mechanism also provides a device-specific mechanism for
-event coalescing or hold-off. For example, a guest OS may request to only
-actually receive an event after {\it n} packets are queued ready for delivery
-to it, {\it t} nanoseconds after the first packet arrived (which ever is true
-first). This allows latency and throughput requirements to be addressed on a
-domain-specific basis.
-
-\chapter{Time}
-Guest operating systems need to be aware of the passage of real time and their
-own ``virtual time'', i.e. the time they have been executing. Furthermore, a
-notion of time is required in the hypervisor itself for scheduling and the
-activities that relate to it. To this end the hypervisor provides for notions
-of time: cycle counter time, system time, wall clock time, domain virtual
-time.
-
-
-\section{Cycle counter time}
-This provides the finest-grained, free-running time reference, with the
-approximate frequency being publicly accessible. The cycle counter time is
-used to accurately extrapolate the other time references. On SMP machines
-it is currently assumed that the cycle counter time is synchronised between
-CPUs. The current x86-based implementation achieves this within inter-CPU
-communication latencies.
-
-\section{System time}
-This is a 64-bit value containing the nanoseconds elapsed since boot
-time. Unlike cycle counter time, system time accurately reflects the
-passage of real time, i.e. it is adjusted several times a second for timer
-drift. This is done by running an NTP client in {\it domain0} on behalf of
-the machine, feeding updates to the hypervisor. Intermediate values can be
-extrapolated using the cycle counter.
-
-\section{Wall clock time}
-This is the actual ``time of day'' Unix style struct timeval (i.e. seconds and
-microseconds since 1 January 1970, adjusted by leap seconds etc.). Again, an
-NTP client hosted by {\it domain0} can help maintain this value. To guest
-operating systems this value will be reported instead of the hardware RTC
-clock value and they can use the system time and cycle counter times to start
-and remain perfectly in time.
-
-
-\section{Domain virtual time}
-This progresses at the same pace as cycle counter time, but only while a
-domain is executing. It stops while a domain is de-scheduled. Therefore the
-share of the CPU that a domain receives is indicated by the rate at which
-its domain virtual time increases, relative to the rate at which cycle
-counter time does so.
-
-\section{Time interface}
-Xen exports some timestamps to guest operating systems through their shared
-info page. Timestamps are provided for system time and wall-clock time. Xen
-also provides the cycle counter values at the time of the last update
-allowing guests to calculate the current values. The cpu frequency and a
-scaling factor are provided for guests to convert cycle counter values to
-real time. Since all time stamps need to be updated and read
-\emph{atomically} two version numbers are also stored in the shared info
-page.
-
-Xen will ensure that the time stamps are updated frequently enough to avoid
-an overflow of the cycle counter values. A guest can check if its notion of
-time is up-to-date by comparing the version numbers.
-
-\section{Timer events}
-
-Xen maintains a periodic timer (currently with a 10ms period) which sends a
-timer event to the currently executing domain. This allows Guest OSes to
-keep track of the passing of time when executing. The scheduler also
-arranges for a newly activated domain to receive a timer event when
-scheduled so that the Guest OS can adjust to the passage of time while it
-has been inactive.
-
-In addition, Xen exports a hypercall interface to each domain which allows
-them to request a timer event sent to them at the specified system
-time. Guest OSes may use this timer to implement timeout values when they
-block.
-
-\chapter{Memory}
-
-The hypervisor is responsible for providing memory to each of the
-domains running over it. However, the Xen hypervisor's duty is
-restricted to managing physical memory and to policying page table
-updates. All other memory management functions are handled
-externally. Start-of-day issues such as building initial page tables
-for a domain, loading its kernel image and so on are done by the {\it
-domain builder} running in user-space in {\it domain0}. Paging to
-disk and swapping is handled by the guest operating systems
-themselves, if they need it.
-
-On a Xen-based system, the hypervisor itself runs in {\it ring 0}. It
-has full access to the physical memory available in the system and is
-responsible for allocating portions of it to the domains. Guest
-operating systems run in and use {\it rings 1}, {\it 2} and {\it 3} as
-they see fit, aside from the fact that segmentation is used to prevent
-the guest OS from accessing a portion of the linear address space that
-is reserved for use by the hypervisor. This approach allows
-transitions between the guest OS and hypervisor without flushing the
-TLB. We expect most guest operating systems will use ring 1 for their
-own operation and place applications (if they support such a notion)
-in ring 3.
-
-\section{Physical Memory Allocation}
-The hypervisor reserves a small fixed portion of physical memory at
-system boot time. This special memory region is located at the
-beginning of physical memory and is mapped at the very top of every
-virtual address space.
-
-Any physical memory that is not used directly by the hypervisor is divided into
-pages and is available for allocation to domains. The hypervisor tracks which
-pages are free and which pages have been allocated to each domain. When a new
-domain is initialized, the hypervisor allocates it pages drawn from the free
-list. The amount of memory required by the domain is passed to the hypervisor
-as one of the parameters for new domain initialization by the domain builder.
-
-Domains can never be allocated further memory beyond that which was
-requested for them on initialization. However, a domain can return
-pages to the hypervisor if it discovers that its memory requirements
-have diminished.
-
-% put reasons for why pages might be returned here.
-\section{Page Table Updates}
-In addition to managing physical memory allocation, the hypervisor is also in
-charge of performing page table updates on behalf of the domains. This is
-neccessary to prevent domains from adding arbitrary mappings to their page
-tables or introducing mappings to other's page tables.
-
-\section{Writabel Page Tables}
-A domain can also request write access to its page tables. In this
-mode, Xen notes write attempts to page table pages and makes the page
-temporarily writable. In-use page table pages are also disconnect
-from the page directory. The domain can now update entries in these
-page table pages without the assistance of Xen. As soon as the
-writabel page table pages get used as page table pages, Xen makes the
-pages read-only again and revalidates the entries in the pages.
-
-\section{Segment Descriptor Tables}
-
-On boot a guest is supplied with a default GDT, which is {\em not}
-taken from its own memory allocation. If the guest wishes to use other
-than the default `flat' ring-1 and ring-3 segments that this default
-table provides, it must register a custom GDT and/or LDT with Xen,
-allocated from its own memory.
-
-int {\bf set\_gdt}(unsigned long *{\em frame\_list}, int {\em entries})
-
-{\em frame\_list}: An array of up to 16 page frames within which the
-GDT resides. Any frame registered as a GDT frame may only be mapped
-read-only within the guest's address space (e.g., no writable
-mappings, no use as a page-table page, and so on).
-
-{\em entries}: The number of descriptor-entry slots in the GDT. Note
-that the table must be large enough to contain Xen's reserved entries;
-thus we must have '{\em entries $>$ LAST\_RESERVED\_GDT\_ENTRY}'.
-Note also that, after registering the GDT, slots {\em FIRST\_} through
-{\em LAST\_RESERVED\_GDT\_ENTRY} are no longer usable by the guest and
-may be overwritten by Xen.
-
-\section{Pseudo-Physical Memory}
-The usual problem of external fragmentation means that a domain is
-unlikely to receive a contiguous stretch of physical memory. However,
-most guest operating systems do not have built-in support for
-operating in a fragmented physical address space e.g. Linux has to
-have a one-to-one mapping for its physical memory. There a notion of
-{\it pseudo physical memory} is introdouced. Xen maintains a {\it
-real physical} to {\it pseudo physical} mapping which can be consulted
-by every domain. Additionally, at its start of day, a domain is
-supplied a {\it pseudo physical} to {\it real physical} mapping which
-it needs to keep updated itself. From that moment onwards {\it pseudo
-physical} addresses are used instead of discontiguous {\it real
-physical} addresses. Thus, the rest of the guest OS code has an
-impression of operating in a contiguous address space. Guest OS page
-tables contain real physical addresses. Mapping {\it pseudo physical}
-to {\it real physical} addresses is needed on page table updates and
-also on remapping memory regions with the guest OS.
-
-
-
-\chapter{Network I/O}
-
-Virtual network device services are provided by shared memory
-communications with a `backend' domain. From the point of view of
-other domains, the backend may be viewed as a virtual ethernet switch
-element with each domain having one or more virtual network interfaces
-connected to it.
-
-\section{Backend Packet Handling}
-The backend driver is responsible primarily for {\it data-path} operations.
-In terms of networking this means packet transmission and reception.
-
-On the transmission side, the backend needs to perform two key actions:
-\begin{itemize}
-\item {\tt Validation:} A domain may only be allowed to emit packets
-matching a certain specification; for example, ones in which the
-source IP address matches one assigned to the virtual interface over
-which it is sent. The backend would be responsible for ensuring any
-such requirements are met, either by checking or by stamping outgoing
-packets with prescribed values for certain fields.
-
-Validation functions can be configured using standard firewall rules
-(i.e. IP Tables, in the case of Linux).
-
-\item {\tt Scheduling:} Since a number of domains can share a single
-``real'' network interface, the hypervisor must mediate access when
-several domains each have packets queued for transmission. Of course,
-this general scheduling function subsumes basic shaping or
-rate-limiting schemes.
-
-\item {\tt Logging and Accounting:} The hypervisor can be configured
-with classifier rules that control how packets are accounted or
-logged. For example, {\it domain0} could request that it receives a
-log message or copy of the packet whenever another domain attempts to
-send a TCP packet containg a SYN.
-\end{itemize}
-
-On the recive side, the backend's role is relatively straightforward:
-once a packet is received, it just needs to determine the virtual interface(s)
-to which it must be delivered and deliver it via page-flipping.
-
-
-\section{Data Transfer}
-
-Each virtual interface uses two ``descriptor rings'', one for transmit,
-the other for receive. Each descriptor identifies a block of contiguous
-physical memory allocated to the domain. There are four cases:
-
-\begin{itemize}
-
-\item The transmit ring carries packets to transmit from the domain to the
-hypervisor.
-
-\item The return path of the transmit ring carries ``empty'' descriptors
-indicating that the contents have been transmitted and the memory can be
-re-used.
-
-\item The receive ring carries empty descriptors from the domain to the
-hypervisor; these provide storage space for that domain's received packets.
-
-\item The return path of the receive ring carries packets that have been
-received.
-\end{itemize}
-
-Real physical addresses are used throughout, with the domain performing
-translation from pseudo-physical addresses if that is necessary.
-
-If a domain does not keep its receive ring stocked with empty buffers then
-packets destined to it may be dropped. This provides some defense against
-receiver-livelock problems because an overload domain will cease to receive
-further data. Similarly, on the transmit path, it provides the application
-with feedback on the rate at which packets are able to leave the system.
-
-Synchronization between the hypervisor and the domain is achieved using
-counters held in shared memory that is accessible to both. Each ring has
-associated producer and consumer indices indicating the area in the ring
-that holds descriptors that contain data. After receiving {\it n} packets
-or {\t nanoseconds} after receiving the first packet, the hypervisor sends
-an event to the domain.
-
-\chapter{Block I/O}
-
-\section{Virtual Block Devices (VBDs)}
-
-All guest OS disk access goes through the VBD interface. The VBD
-interface provides the administrator with the ability to selectively
-grant domains access to portions of block storage devices visible to
-the the block backend device (usually domain 0).
-
-VBDs can literally be backed by any block device accessible to the
-backend domain, including network-based block devices (iSCSI, *NBD,
-etc), loopback devices and LVM / MD devices.
-
-Old (Xen 1.2) virtual disks are not supported under Xen 2.0, since
-similar functionality can be achieved using the (more advanced) LVM
-system, which is already in widespread use.
-
-\subsection{Data Transfer}
-Domains which have been granted access to a logical block device are permitted
-to read and write it by shared memory communications with the backend domain.
-
-In overview, the same style of descriptor-ring that is used for
-network packets is used here. Each domain has one ring that carries
-operation requests to the hypervisor and carries the results back
-again.
-
-Rather than copying data, the backend simply maps the domain's buffers
-in order to enable direct DMA to them. The act of mapping the buffers
-also increases the reference counts of the underlying pages, so that
-the unprivileged domain cannot try to return them to the hypervisor,
-install them as page tables, or any other unsafe behaviour.
-%block API here
-
-\chapter{Privileged operations}
-{\it Domain0} is responsible for building all other domains on the server
-and providing control interfaces for managing scheduling, networking, and
-blocks.
-
-\chapter{CPU Scheduler}
-
-Xen offers a uniform API for CPU schedulers. It is possible to choose
-from a number of schedulers at boot and it should be easy to add more.
-
-\paragraph*{Note: SMP host support}
-Xen has always supported SMP host systems. Domains are statically assigned to
-CPUs, either at creation time or when manually pinning to a particular CPU.
-The current schedulers then run locally on each CPU to decide which of the
-assigned domains should be run there.
-
-\section{Standard Schedulers}
-
-These BVT, Atropos and Round Robin schedulers are part of the normal
-Xen distribution. BVT provides proportional fair shares of the CPU to
-the running domains. Atropos can be used to reserve absolute shares
-of the CPU for each domain. Round-robin is provided as an example of
-Xen's internal scheduler API.
-
-More information on the characteristics and use of these schedulers is
-available in { \tt Sched-HOWTO.txt }.
-
-\section{Scheduling API}
-
-The scheduling API is used by both the schedulers described above and should
-also be used by any new schedulers. It provides a generic interface and also
-implements much of the ``boilerplate'' code.
-
-Schedulers conforming to this API are described by the following
-structure:
-
-\begin{verbatim}
-struct scheduler
-{
- char *name; /* full name for this scheduler */
- char *opt_name; /* option name for this scheduler */
- unsigned int sched_id; /* ID for this scheduler */
-
- int (*init_scheduler) ();
- int (*alloc_task) (struct task_struct *);
- void (*add_task) (struct task_struct *);
- void (*free_task) (struct task_struct *);
- void (*rem_task) (struct task_struct *);
- void (*wake_up) (struct task_struct *);
- void (*do_block) (struct task_struct *);
- task_slice_t (*do_schedule) (s_time_t);
- int (*control) (struct sched_ctl_cmd *);
- int (*adjdom) (struct task_struct *,
- struct sched_adjdom_cmd *);
- s32 (*reschedule) (struct task_struct *);
- void (*dump_settings) (void);
- void (*dump_cpu_state) (int);
- void (*dump_runq_el) (struct task_struct *);
-};
-\end{verbatim}
-
-The only method that {\em must} be implemented is
-{\tt do\_schedule()}. However, if there is not some implementation for the
-{\tt wake\_up()} method then waking tasks will not get put on the runqueue!
-
-The fields of the above structure are described in more detail below.
-
-\subsubsection{name}
-
-The name field should point to a descriptive ASCII string.
-
-\subsubsection{opt\_name}
-
-This field is the value of the {\tt sched=} boot-time option that will select
-this scheduler.
-
-\subsubsection{sched\_id}
-
-This is an integer that uniquely identifies this scheduler. There should be a
-macro corrsponding to this scheduler ID in {\tt <hypervisor-ifs/sched-if.h>}.
-
-\subsubsection{init\_scheduler}
-
-\paragraph*{Purpose}
-
-This is a function for performing any scheduler-specific initialisation. For
-instance, it might allocate memory for per-CPU scheduler data and initialise it
-appropriately.
-
-\paragraph*{Call environment}
-
-This function is called after the initialisation performed by the generic
-layer. The function is called exactly once, for the scheduler that has been
-selected.
-
-\paragraph*{Return values}
-
-This should return negative on failure --- this will cause an
-immediate panic and the system will fail to boot.
-
-\subsubsection{alloc\_task}
-
-\paragraph*{Purpose}
-Called when a {\tt task\_struct} is allocated by the generic scheduler
-layer. A particular scheduler implementation may use this method to
-allocate per-task data for this task. It may use the {\tt
-sched\_priv} pointer in the {\tt task\_struct} to point to this data.
-
-\paragraph*{Call environment}
-The generic layer guarantees that the {\tt sched\_priv} field will
-remain intact from the time this method is called until the task is
-deallocated (so long as the scheduler implementation does not change
-it explicitly!).
-
-\paragraph*{Return values}
-Negative on failure.
-
-\subsubsection{add\_task}
-
-\paragraph*{Purpose}
-
-Called when a task is initially added by the generic layer.
-
-\paragraph*{Call environment}
-
-The fields in the {\tt task\_struct} are now filled out and available for use.
-Schedulers should implement appropriate initialisation of any per-task private
-information in this method.
-
-\subsubsection{free\_task}
-
-\paragraph*{Purpose}
-
-Schedulers should free the space used by any associated private data
-structures.
-
-\paragraph*{Call environment}
-
-This is called when a {\tt task\_struct} is about to be deallocated.
-The generic layer will have done generic task removal operations and
-(if implemented) called the scheduler's {\tt rem\_task} method before
-this method is called.
-
-\subsubsection{rem\_task}
-
-\paragraph*{Purpose}
-
-This is called when a task is being removed from scheduling (but is
-not yet being freed).
-
-\subsubsection{wake\_up}
-
-\paragraph*{Purpose}
-
-Called when a task is woken up, this method should put the task on the runqueue
-(or do the scheduler-specific equivalent action).
-
-\paragraph*{Call environment}
-
-The task is already set to state RUNNING.
-
-\subsubsection{do\_block}
-
-\paragraph*{Purpose}
-
-This function is called when a task is blocked. This function should
-not remove the task from the runqueue.
-
-\paragraph*{Call environment}
-
-The EVENTS\_MASTER\_ENABLE\_BIT is already set and the task state changed to
-TASK\_INTERRUPTIBLE on entry to this method. A call to the {\tt
- do\_schedule} method will be made after this method returns, in
-order to select the next task to run.
-
-\subsubsection{do\_schedule}
-
-This method must be implemented.
-
-\paragraph*{Purpose}
-
-The method is called each time a new task must be chosen for scheduling on the
-current CPU. The current time as passed as the single argument (the current
-task can be found using the {\tt current} macro).
-
-This method should select the next task to run on this CPU and set it's minimum
-time to run as well as returning the data described below.
-
-This method should also take the appropriate action if the previous
-task has blocked, e.g. removing it from the runqueue.
-
-\paragraph*{Call environment}
-
-The other fields in the {\tt task\_struct} are updated by the generic layer,
-which also performs all Xen-specific tasks and performs the actual task switch
-(unless the previous task has been chosen again).
-
-This method is called with the {\tt schedule\_lock} held for the current CPU
-and local interrupts disabled.
-
-\paragraph*{Return values}
-
-Must return a {\tt struct task\_slice} describing what task to run and how long
-for (at maximum).
-
-\subsubsection{control}
-
-\paragraph*{Purpose}
-
-This method is called for global scheduler control operations. It takes a
-pointer to a {\tt struct sched\_ctl\_cmd}, which it should either
-source data from or populate with data, depending on the value of the
-{\tt direction} field.
-
-\paragraph*{Call environment}
-
-The generic layer guarantees that when this method is called, the
-caller selected the correct scheduler ID, hence the scheduler's
-implementation does not need to sanity-check these parts of the call.
-
-\paragraph*{Return values}
-
-This function should return the value to be passed back to user space, hence it
-should either be 0 or an appropriate errno value.
-
-\subsubsection{sched\_adjdom}
-
-\paragraph*{Purpose}
-
-This method is called to adjust the scheduling parameters of a particular
-domain, or to query their current values. The function should check
-the {\tt direction} field of the {\tt sched\_adjdom\_cmd} it receives in
-order to determine which of these operations is being performed.
-
-\paragraph*{Call environment}
-
-The generic layer guarantees that the caller has specified the correct
-control interface version and scheduler ID and that the supplied {\tt
-task\_struct} will not be deallocated during the call (hence it is not
-necessary to {\tt get\_task\_struct}).
-
-\paragraph*{Return values}
-
-This function should return the value to be passed back to user space, hence it
-should either be 0 or an appropriate errno value.
-
-\subsubsection{reschedule}
-
-\paragraph*{Purpose}
-
-This method is called to determine if a reschedule is required as a result of a
-particular task.
-
-\paragraph*{Call environment}
-The generic layer will cause a reschedule if the current domain is the idle
-task or it has exceeded its minimum time slice before a reschedule. The
-generic layer guarantees that the task passed is not currently running but is
-on the runqueue.
-
-\paragraph*{Return values}
-
-Should return a mask of CPUs to cause a reschedule on.
-
-\subsubsection{dump\_settings}
-
-\paragraph*{Purpose}
-
-If implemented, this should dump any private global settings for this
-scheduler to the console.
-
-\paragraph*{Call environment}
-
-This function is called with interrupts enabled.
-
-\subsubsection{dump\_cpu\_state}
-
-\paragraph*{Purpose}
-
-This method should dump any private settings for the specified CPU.
-
-\paragraph*{Call environment}
-
-This function is called with interrupts disabled and the {\tt schedule\_lock}
-for the specified CPU held.
-
-\subsubsection{dump\_runq\_el}
-
-\paragraph*{Purpose}
-
-This method should dump any private settings for the specified task.
-
-\paragraph*{Call environment}
-
-This function is called with interrupts disabled and the {\tt schedule\_lock}
-for the task's CPU held.
-
-
-\chapter{Debugging}
-
-Xen provides tools for debugging both Xen and guest OSes. Currently, the
-Pervasive Debugger provides a GDB stub, which provides facilities for symbolic
-debugging of Xen itself and of OS kernels running on top of Xen. The Trace
-Buffer provides a lightweight means to log data about Xen's internal state and
-behaviour at runtime, for later analysis.
-
-\section{Pervasive Debugger}
-
-Information on using the pervasive debugger is available in pdb.txt.
-
-
-\section{Trace Buffer}
-
-The trace buffer provides a means to observe Xen's operation from domain 0.
-Trace events, inserted at key points in Xen's code, record data that can be
-read by the {\tt xentrace} tool. Recording these events has a low overhead
-and hence the trace buffer may be useful for debugging timing-sensitive
-behaviours.
-
-\subsection{Internal API}
-
-To use the trace buffer functionality from within Xen, you must {\tt \#include
-<xen/trace.h>}, which contains definitions related to the trace buffer. Trace
-events are inserted into the buffer using the {\tt TRACE\_xD} ({\tt x} = 0, 1,
-2, 3, 4 or 5) macros. These all take an event number, plus {\tt x} additional
-(32-bit) data as their arguments. For trace buffer-enabled builds of Xen these
-will insert the event ID and data into the trace buffer, along with the current
-value of the CPU cycle-counter. For builds without the trace buffer enabled,
-the macros expand to no-ops and thus can be left in place without incurring
-overheads.
-
-\subsection{Trace-enabled builds}
-
-By default, the trace buffer is enabled only in debug builds (i.e. {\tt NDEBUG}
-is not defined). It can be enabled separately by defining {\tt TRACE\_BUFFER},
-either in {\tt <xen/config.h>} or on the gcc command line.
-
-The size (in pages) of the per-CPU trace buffers can be specified using the
-{\tt tbuf\_size=n } boot parameter to Xen. If the size is set to 0, the trace
-buffers will be disabled.
-
-\subsection{Dumping trace data}
-
-When running a trace buffer build of Xen, trace data are written continuously
-into the buffer data areas, with newer data overwriting older data. This data
-can be captured using the {\tt xentrace} program in Domain 0.
-
-The {\tt xentrace} tool uses {\tt /dev/mem} in domain 0 to map the trace
-buffers into its address space. It then periodically polls all the buffers for
-new data, dumping out any new records from each buffer in turn. As a result,
-for machines with multiple (logical) CPUs, the trace buffer output will not be
-in overall chronological order.
-
-The output from {\tt xentrace} can be post-processed using {\tt
-xentrace\_cpusplit} (used to split trace data out into per-cpu log files) and
-{\tt xentrace\_format} (used to pretty-print trace data). For the predefined
-trace points, there is an example format file in {\tt tools/xentrace/formats }.
-
-For more information, see the manual pages for {\tt xentrace}, {\tt
-xentrace\_format} and {\tt xentrace\_cpusplit}.
-
-
-\chapter{Hypervisor calls}
-
-\section{ set\_trap\_table(trap\_info\_t *table)}
-
-Install trap handler table.
-
-\section{ mmu\_update(mmu\_update\_t *req, int count, int *success\_count)}
-Update the page table for the domain. Updates can be batched.
-success\_count will be updated to report the number of successfull
-updates. The update types are:
-
-{\it MMU\_NORMAL\_PT\_UPDATE}:
-
-{\it MMU\_MACHPHYS\_UPDATE}:
-
-{\it MMU\_EXTENDED\_COMMAND}:
-
-\section{ set\_gdt(unsigned long *frame\_list, int entries)}
-Set the global descriptor table - virtualization for lgdt.
-
-\section{ stack\_switch(unsigned long ss, unsigned long esp)}
-Request context switch from hypervisor.
-
-\section{ set\_callbacks(unsigned long event\_selector, unsigned long event\_address,
- unsigned long failsafe\_selector, unsigned
- long failsafe\_address) } Register OS event processing routine. In
- Linux both the event\_selector and failsafe\_selector are the
- kernel's CS. The value event\_address specifies the address for an
- interrupt handler dispatch routine and failsafe\_address specifies a
- handler for application faults.
-
-\section{ fpu\_taskswitch(void)}
-Notify hypervisor that fpu registers needed to be save on context switch.
-
-\section{ sched\_op(unsigned long op)}
-Request scheduling operation from hypervisor. The options are: {\it
-yield}, {\it block}, and {\it shutdown}. {\it yield} keeps the
-calling domain run-able but may cause a reschedule if other domains
-are run-able. {\it block} removes the calling domain from the run
-queue and the domains sleeps until an event is delivered to it. {\it
-shutdown} is used to end the domain's execution and allows to specify
-whether the domain should reboot, halt or suspend..
-
-\section{ dom0\_op(dom0\_op\_t *op)}
-Administrative domain operations for domain management. The options are:
-
-{\it DOM0\_CREATEDOMAIN}: create new domain, specifying the name and memory usage
-in kilobytes.
-
-{\it DOM0\_CREATEDOMAIN}: create domain
-
-{\it DOM0\_PAUSEDOMAIN}: mark domain as unschedulable
-
-{\it DOM0\_UNPAUSEDOMAIN}: mark domain as schedulable
-
-{\it DOM0\_DESTROYDOMAIN}: deallocate resources associated with the domain
-
-{\it DOM0\_GETMEMLIST}: get list of pages used by the domain
-
-{\it DOM0\_SCHEDCTL}:
-
-{\it DOM0\_ADJUSTDOM}: adjust scheduling priorities for domain
-
-{\it DOM0\_BUILDDOMAIN}: do final guest OS setup for domain
-
-{\it DOM0\_GETDOMAINFO}: get statistics about the domain
-
-{\it DOM0\_GETPAGEFRAMEINFO}:
-
-{\it DOM0\_IOPL}: set IO privilege level
-
-{\it DOM0\_MSR}:
-
-{\it DOM0\_DEBUG}: interactively call pervasive debugger
-
-{\it DOM0\_SETTIME}: set system time
-
-{\it DOM0\_READCONSOLE}: read console content from hypervisor buffer ring
-
-{\it DOM0\_PINCPUDOMAIN}: pin domain to a particular CPU
-
-{\it DOM0\_GETTBUFS}: get information about the size and location of
- the trace buffers (only on trace-buffer enabled builds)
-
-{\it DOM0\_PHYSINFO}: get information about the host machine
-
-{\it DOM0\_PCIDEV\_ACCESS}: modify PCI device access permissions
-
-{\it DOM0\_SCHED\_ID}: get the ID of the current Xen scheduler
-
-{\it DOM0\_SHADOW\_CONTROL}:
-
-{\it DOM0\_SETDOMAINNAME}: set the name of a domain
-
-{\it DOM0\_SETDOMAININITIALMEM}: set initial memory allocation of a domain
-
-{\it DOM0\_SETDOMAINMAXMEM}: set maximum memory allocation of a domain
-
-{\it DOM0\_GETPAGEFRAMEINFO2}:
-
-{\it DOM0\_SETDOMAINVMASSIST}: set domain VM assist options
-
-
-\section{ set\_debugreg(int reg, unsigned long value)}
-set debug register reg to value
-
-\section{ get\_debugreg(int reg)}
- get the debug register reg
-
-\section{ update\_descriptor(unsigned long ma, unsigned long word1, unsigned long word2)}
-
-\section{ set\_fast\_trap(int idx)}
- install traps to allow guest OS to bypass hypervisor
-
-\section{ dom\_mem\_op(unsigned int op, unsigned long *extent\_list, unsigned long nr\_extents, unsigned int extent\_order)}
-Increase or decrease memory reservations for guest OS
-
-\section{ multicall(void *call\_list, int nr\_calls)}
-Execute a series of hypervisor calls
-
-\section{ update\_va\_mapping(unsigned long page\_nr, unsigned long val, unsigned long flags)}
-
-\section{ set\_timer\_op(uint64\_t timeout)}
-Request a timer event to be sent at the specified system time.
-
-\section{ event\_channel\_op(void *op)}
-Iinter-domain event-channel management.
-
-\section{ xen\_version(int cmd)}
-Request Xen version number.
-
-\section{ console\_io(int cmd, int count, char *str)}
-Interact with the console, operations are:
-
-{\it CONSOLEIO\_write}: Output count characters from buffer str.
-
-{\it CONSOLEIO\_read}: Input at most count characters into buffer str.
-
-\section{ physdev\_op(void *physdev\_op)}
-
-\section{ grant\_table\_op(unsigned int cmd, void *uop, unsigned int count)}
-
-\section{ vm\_assist(unsigned int cmd, unsigned int type)}
-
-\section{ update\_va\_mapping\_otherdomain(unsigned long page\_nr, unsigned long val, unsigned long flags, uint16\_t domid)}
-
-\end{document}
--- /dev/null
+Pervasive Debugging
+===================
+
+Alex Ho (alex.ho at cl.cam.ac.uk)
+
+Introduction
+------------
+
+The pervasive debugging project is leveraging Xen to
+debug distributed systems. We have added a gdb stub
+to Xen to allow for remote debugging of both Xen and
+guest operating systems. More information about the
+pervasive debugger is available at: http://www.cl.cam.ac.uk/netos/pdb
+
+
+Implementation
+--------------
+
+The gdb stub communicates with gdb running over a serial line.
+The main entry point is pdb_handle_exception() which is invoked
+from: pdb_key_pressed() ('D' on the console)
+ do_int3_exception() (interrupt 3: breakpoint exception)
+ do_debug() (interrupt 1: debug exception)
+
+This accepts characters from the serial port and passes gdb
+commands to pdb_process_command() which implements the gdb stub
+interface. This file draws heavily from the kgdb project and
+sample gdbstub provided with gdb.
+
+The stub can examine registers, single step and continue, and
+read and write memory (in Xen, a domain, or a Linux process'
+address space). The debugger does not currently trace the
+current process, so all bets are off if context switch occurs
+in the domain.
+
+
+Setup
+-----
+
+ +-------+ telnet +-----------+ serial +-------+
+ | GDB |--------| nsplitd |--------| Xen |
+ +-------+ +-----------+ +-------+
+
+To run pdb, Xen must be appropriately configured and
+a suitable serial interface attached to the target machine.
+GDB and nsplitd can run on the same machine.
+
+Xen Configuration
+
+ Add the "pdb=xxx" option to your Xen boot command line
+ where xxx is one of the following values:
+ com1 gdb stub should communicate on com1
+ com1H gdb stub should communicate on com1 (with high bit set)
+ com2 gdb stub should communicate on com2
+ com2H gdb stub should communicate on com2 (with high bit set)
+
+ Symbolic debugging infomration is quite helpful too:
+ xeno.bk/xen/arch/x86/Rules.mk
+ add -g to CFLAGS to compile Xen with symbols
+ xeno.bk/linux-2.4.27-xen-sparse/arch/xen/Makefile
+ add -g to CFLAGS to compile Linux with symbols
+
+ You may also want to consider dedicating a register to the
+ frame pointer (disable the -fomit-frame-pointer compile flag).
+
+ When booting Xen and domain 0, look for the console text
+ "pdb: pervasive debugger" just before DOM0 starts up.
+
+Serial Port Configuration
+
+ pdb expects to communicate with gdb using the serial port. Since
+ this port is often shared with the machine's console output, pdb can
+ discriminate its communication by setting the high bit of each byte.
+
+ A new tool has been added to the source tree which splits
+ the serial output from a remote machine into two streams:
+ one stream (without the high bit) is the console and
+ one stream (with the high bit stripped) is the pdb communication.
+
+ See: xeno.bk/tools/misc/nsplitd
+
+ nsplitd configuration
+ ---------------------
+ hostname$ more /etc/xinetd.d/nsplit
+ service nsplit1
+ {
+ socket_type = stream
+ protocol = tcp
+ wait = no
+ user = wanda
+ server = /usr/sbin/in.nsplitd
+ server_args = serial.cl.cam.ac.uk:wcons00
+ disable = no
+ only_from = 128.232.0.0/17 127.0.0.1
+ }
+
+ hostname$ egrep 'wcons00|nsplit1' /etc/services
+ wcons00 9600/tcp # Wanda remote console
+ nsplit1 12010/tcp # Nemesis console splitter ports.
+
+ Note: nsplitd was originally written for the Nemesis project
+ at Cambridge.
+
+ After nsplitd accepts a connection on <port> (12010 in the above
+ example), it starts listening on port <port + 1>. Characters sent
+ to the <port + 1> will have the high bit set and vice versa for
+ characters received.
+
+ You can connect to the nsplitd using
+ 'tools/misc/xencons <host> <port>'
+
+GDB 6.0
+ pdb has been tested with gdb 6.0. It should also work with
+ earlier versions.
+
+
+Usage
+-----
+
+1. Boot Xen and Linux
+2. Interrupt Xen by pressing 'D' at the console
+ You should see the console message:
+ (XEN) pdb_handle_exception [0x88][0x101000:0xfc5e72ac]
+ At this point Xen is frozen and the pdb stub is waiting for gdb commands
+ on the serial line.
+3. Attach with gdb
+ (gdb) file xeno.bk/xen/xen
+ Reading symbols from xeno.bk/xen/xen...done.
+ (gdb) target remote <hostname>:<port + 1> /* contact nsplitd */
+ Remote debugging using serial.srg:12131
+ continue_cpu_idle_loop () at current.h:10
+ warning: shared library handler failed to enable breakpoint
+ (gdb) break __enter_scheduler
+ Breakpoint 1 at 0xfc510a94: file schedule.c, line 330.
+ (gdb) cont
+ Continuing.
+
+ Program received signal SIGTRAP, Trace/breakpoint trap.
+ __enter_scheduler () at schedule.c:330
+ (gdb) step
+ (gdb) step
+ (gdb) print next /* the variable prev has been optimized away! */
+ $1 = (struct task_struct *) 0x0
+ (gdb) delete
+ Delete all breakpoints? (y or n) y
+4. You can add additional symbols to gdb
+ (gdb) add-sym xeno.bk/linux-2.4.27-xen0/vmlinux
+ add symbol table from file "xeno.bk/linux-2.4.27-xen0/vmlinux" at
+ (y or n) y
+ Reading symbols from xeno.bk/linux-2.4.27-xen0/vmlinux...done.
+ (gdb) x/s cpu_vendor_names[0]
+ 0xc01530d2 <cpdext+62898>: "Intel"
+ (gdb) break free_uid
+ Breakpoint 2 at 0xc0012250
+ (gdb) cont
+ Continuing. /* run a command in domain 0 */
+
+ Program received signal SIGTRAP, Trace/breakpoint trap.
+ free_uid (up=0xbffff738) at user.c:77
+
+ (gdb) print *up
+ $2 = {__count = {counter = 0}, processes = {counter = 135190120}, files = {
+ counter = 0}, next = 0x395, pprev = 0xbffff878, uid = 134701041}
+ (gdb) finish
+ Run till exit from #0 free_uid (up=0xbffff738) at user.c:77
+
+ Program received signal SIGTRAP, Trace/breakpoint trap.
+ release_task (p=0xc2da0000) at exit.c:51
+ (gdb) print *p
+ $3 = {state = 4, flags = 4, sigpending = 0, addr_limit = {seg = 3221225472},
+ exec_domain = 0xc016a040, need_resched = 0, ptrace = 0, lock_depth = -1,
+ counter = 1, nice = 0, policy = 0, mm = 0x0, processor = 0,
+ cpus_runnable = 1, cpus_allowed = 4294967295, run_list = {next = 0x0,
+ prev = 0x0}, sleep_time = 18995, next_task = 0xc017c000,
+ prev_task = 0xc2f94000, active_mm = 0x0, local_pages = {next = 0xc2da0054,
+ prev = 0xc2da0054}, allocation_order = 0, nr_local_pages = 0,
+ ...
+5. To resume Xen, enter the "continue" command to gdb.
+ This sends the packet $c#63 along the serial channel.
+
+ (gdb) cont
+ Continuing.
+
+Debugging Multiple Domains & Processes
+--------------------------------------
+
+pdb supports debugging multiple domains & processes. You can switch
+between different domains and processes within domains and examine
+variables in each.
+
+The pdb context identifies the current debug target. It is stored
+in the xen variable pdb_ctx and defaults to xen.
+
+ target pdb_ctx.domain pdb_ctx.process
+ ------ -------------- ---------------
+ xen -1 -1
+ guest os 0,1,2,... -1
+ process 0,1,2,... 0,1,2,...
+
+Unfortunately, gdb doesn't understand debugging multiple process
+simultaneously (we're working on it), so at present you are limited
+to just one set of symbols for symbolic debugging. When debugging
+processes, pdb currently supports just Linux 2.4.
+
+ define setup
+ file xeno-clone/xeno.bk/xen/xen
+ add-sym xeno-clone/xeno.bk/linux-2.4.27-xen0/vmlinux
+ add-sym ~ach61/a.out
+ end
+
+
+1. Connect with gdb as before. A couple of Linux-specific
+ symbols need to be defined.
+
+ (gdb) target remote <hostname>:<port + 1> /* contact nsplitd */
+ Remote debugging using serial.srg:12131
+ continue_cpu_idle_loop () at current.h:10
+ warning: shared library handler failed to enable breakpoint
+ (gdb) set pdb_pidhash_addr = &pidhash
+ (gdb) set pdb_init_task_union_addr = &init_task_union
+
+2. The pdb context defaults to Xen and we can read Xen's memory.
+ An attempt to access domain 0 memory fails.
+
+ (gdb) print pdb_ctx
+ $1 = {valid = 0, domain = -1, process = -1, ptbr = 1052672}
+ (gdb) print hexchars
+ $2 = "0123456789abcdef"
+ (gdb) print cpu_vendor_names
+ Cannot access memory at address 0xc0191f80
+
+3. Now we change to domain 0. In addition to changing pdb_ctx.domain,
+ we need to change pdb_ctx.valid to signal pdb of the change.
+ It is now possible to examine Xen and Linux memory.
+
+ (gdb) set pdb_ctx.domain=0
+ (gdb) set pdb_ctx.valid=1
+ (gdb) print hexchars
+ $3 = "0123456789abcdef"
+ (gdb) print cpu_vendor_names
+ $4 = {0xc0158b46 "Intel", 0xc0158c37 "Cyrix", 0xc0158b55 "AMD",
+ 0xc0158c3d "UMC", 0xc0158c41 "NexGen", 0xc0158c48 "Centaur",
+ 0xc0158c50 "Rise", 0xc0158c55 "Transmeta"}
+
+4. Now change to a process within domain 0. Again, we need to
+ change pdb_ctx.valid in addition to pdb_ctx.process.
+
+ (gdb) set pdb_ctx.process=962
+ (gdb) set pdb_ctx.valid =1
+ (gdb) print pdb_ctx
+ $1 = {valid = 0, domain = 0, process = 962, ptbr = 52998144}
+ (gdb) print aho_a
+ $2 = 20
+
+5. Now we can read the same variable from another process running
+ the same executable in another domain.
+
+ (gdb) set pdb_ctx.domain=1
+ (gdb) set pdb_ctx.process=1210
+ (gdb) set pdb_ctx.valid=1
+ (gdb) print pdb_ctx
+ $3 = {valid = 0, domain = 1, process = 1210, ptbr = 70574080}
+ (gdb) print aho_a
+ $4 = 27
+
+
+Some Helpful .gdbinit Commands
+------------------------------
+
+define setup
+ file .../install/boot/xen-syms
+ add-sym .../install/boot/vmlinux-syms-2.4.27-xen0
+ add-sym /homes/aho/a.out
+end
+document setup
+ load symbols for xen, xenolinux (dom 0), and "a.out"
+end
+
+define setup-linux
+ set pdb_pidhash_addr = &pidhash
+ set pdb_init_task_union_addr = &init_task_union
+
+ set task_struct_mm_offset = (void *)&(init_task_union.task.mm) - (void *)&(init_task_union.task)
+ set task_struct_next_task_offset = (void *)&(init_task_union.task.next_task) - (void *)&(init_task_union.task)
+ set task_struct_pid_offset = (void *)&(init_task_union.task.pid) - (void *)&(init_task_union.task)
+ set task_struct_pidhash_next_offset = (void *)&(init_task_union.task.pidhash_next) - (void *)&(init_task_union.task)
+ set task_struct_comm_offset = (void *)&(init_task_union.task.comm) - (void *)&(init_task_union.task)
+ set task_struct_comm_length = sizeof (init_task_union.task.comm)
+
+ set mm_struct_pgd_offset = sizeof (struct vm_area_struct *) * 2 + sizeof (rb_root_t)
+end
+document setup-linux
+ define various xenolinux specific offsets and sizes in pdb
+end
+
+
+
+
+Changes
+-------
+
+04.07.15 aho .gdbinit
+04.02.05 aho creation
+04.03.31 aho add description on debugging multiple domains
--- /dev/null
+=== How the Blkif Drivers Work ===
+Andrew Warfield
+andrew.warfield@cl.cam.ac.uk
+
+The intent of this is to explain at a fairly detailed level how the
+split device drivers work in Xen 1.3 (aka 2.0beta). The intended
+audience for this, I suppose, is anyone who intends to work with the
+existing blkif interfaces and wants something to help them get up to
+speed with the code in a hurry. Secondly though, I hope to break out
+the general mechanisms that are used in the drivers that are likely to
+be necessary to implement other drivers interfaces.
+
+As a point of warning before starting, it is worth mentioning that I
+anticipate much of the specifics described here changing in the near
+future. There has been talk about making the blkif protocol
+a bit more efficient than it currently is. Keir's addition of grant
+tables will change the current remapping code that is used when shared
+pages are initially set up.
+
+Also, writing other control interface types will likely need support
+from Xend, which at the moment has a steep learning curve... this
+should be addressed in the future.
+
+For more information on the driver model as a whole, read the
+"Reconstructing I/O" technical report
+(http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2004-xenngio.pdf).
+
+==== High-level structure of a split-driver interface ====
+
+Why would you want to write a split driver in the first place? As Xen
+is a virtual machine manager and focuses on isolation as an initial
+design principle, it is generally considered unwise to share physical
+access to devices across domains. The reasons for this are obvious:
+when device resources are shared, misbehaving code or hardware can
+result in the failure of all of the client applications. Moreover, as
+virtual machines in Xen are entire OSs, standard device drives that
+they might use cannot have multiple instantiations for a single piece
+of hardware. In light of all this, the general approach in Xen is to
+give a single virtual machine hardware access to a device, and where
+other VMs want to share the device, export a higher-level interface to
+facilitate that sharing. If you don't want to share, that's fine.
+There are currently Xen users actively exploring running two
+completely isolated X-Servers on a Xen host, each with it's own video
+card, keyboard, and mouse. In these situations, the guests need only
+be given physical access to the necessary devices and left to go on
+their own. However, for devices such as disks and network interfaces,
+where sharing is required, the split driver approach is a good
+solution.
+
+The structure is like this:
+
+ +--------------------------+ +--------------------------+
+ | Domain 0 (privileged) | | Domain 1 (unprivileged) |
+ | | | |
+ | Xend ( Application ) | | |
+ | Blkif Backend Driver | | Blkif Frontend Driver |
+ | Physical Device Driver | | |
+ +--------------------------+ +--------------------------+
+ +--------------------------------------------------------+
+ | X E N |
+ +--------------------------------------------------------+
+
+
+The Blkif driver is in two parts, which we refer to as frontend (FE)
+and a backend (BE). Together, they serve to proxy device requests
+between the guest operating system in an unprivileged domain, and the
+physical device driver in the physical domain. An additional benefit
+to this approach is that the FE driver can provide a single interface
+for a whole class of physical devices. The blkif interface mounts
+IDE, SCSI, and our own VBD-structured disks, independent of the
+physical driver underneath. Moreover, supporting additional OSs only
+requires that a new FE driver be written to connect to the existing
+backend.
+
+==== Inter-Domain Communication Mechanisms ====
+
+===== Event Channels =====
+
+Before getting into the specifics of the block interface driver, it is
+worth discussing the mechanisms that are used to communicate between
+domains. Two mechanisms are used to allow the construction of
+high-performance drivers: event channels and shared-memory rings.
+
+Event channels are an asynchronous interdomain notification
+mechanism. Xen allows channels to be instantiated between two
+domains, and domains can request that a virtual irq be attached to
+notifications on a given channel. The result of this is that the
+frontend domain can send a notification on an event channel, resulting
+in an interrupt entry into the backend at a later time.
+
+The event channel between two domains is instantiated in the Xend code
+during driver startup (described later). Xend's channel.py
+(tools/python/xen/xend/server/channel.py) defines the function
+
+
+def eventChannel(dom1, dom2):
+ return xc.evtchn_bind_interdomain(dom1=dom1, dom2=dom2)
+
+
+which maps to xc_evtchn_bind_interdomain() in tools/libxc/xc_evtchn.c,
+which in turn generates a hypercall to Xen to patch the event channel
+between the domains. Only a privileged domain can request the
+creation of an event channel.
+
+Once the event channel is created in Xend, its ends are passed to both the
+front and backend domains over the control channel. The end that is
+passed to a domain is just an integer "port" uniquely identifying the
+event channel's local connection to that domain. An example of this
+setup code is in linux-2.6.x/drivers/xen/blkfront/blkfront.c in
+blkif_status_change, which receives several status change events as
+the driver starts up. It is passed an event channel end in a
+BLKIF_INTERFACE_STATUS_CONNECTED message, and patches it in like this:
+
+
+ blkif_evtchn = status->evtchn;
+ blkif_irq = bind_evtchn_to_irq(blkif_evtchn);
+ if ( (rc = request_irq(blkif_irq, blkif_int,
+ SA_SAMPLE_RANDOM, "blkif", NULL)) )
+ printk(KERN_ALERT"blkfront request_irq failed (%ld)\n",rc);
+
+
+This code associates a virtual irq with the event channel, and
+attaches the function blkif_int() as an interrupt handler for that
+irq. blkif_int() simply handles the notification and returns, it does
+not need to interact with the channel at all.
+
+An example of generating a notification can also be seen in blkfront.c:
+
+
+static inline void flush_requests(void)
+{
+ DISABLE_SCATTERGATHER();
+ wmb(); /* Ensure that the frontend can see the requests. */
+ blk_ring->req_prod = req_prod;
+ notify_via_evtchn(blkif_evtchn);
+}
+}}}
+
+notify_via_evtchn issues a hypercall to set the event waiting flag on
+the other domain's end of the channel.
+
+===== Communication Rings =====
+
+Event channels are strictly a notification mechanism between domains.
+To move large chunks of data back and forth, Xen allows domains to
+share pages of memory. We use communication rings as a means of
+managing access to a shared memory page for message passing between
+domains. These rings are not explicitly a mechanism of Xen, which is
+only concerned with the actual sharing of the page and not how it is
+used, they are however worth discussing as they are used in many
+places in the current code and are a useful model for communicating
+across a shared page.
+
+A shared page is set up by a guest first allocating and passing the
+address of a page in its own address space to the backend driver.
+
+
+ blk_ring = (blkif_ring_t *)__get_free_page(GFP_KERNEL);
+ blk_ring->req_prod = blk_ring->resp_prod = resp_cons = req_prod = 0;
+ ...
+ /* Construct an interface-CONNECT message for the domain controller. */
+ cmsg.type = CMSG_BLKIF_FE;
+ cmsg.subtype = CMSG_BLKIF_FE_INTERFACE_CONNECT;
+ cmsg.length = sizeof(blkif_fe_interface_connect_t);
+ up.handle = 0;
+ up.shmem_frame = virt_to_machine(blk_ring) >> PAGE_SHIFT;
+ memcpy(cmsg.msg, &up, sizeof(up));
+
+
+blk_ring will be the shared page. The producer and consumer pointers
+are then initialised (these will be discussed soon), and then the
+machine address of the page is send to the backend via a control
+channel to Xend. This control channel itself uses the notification
+and shared memory mechanisms described here, but is set up for each
+domain automatically at startup.
+
+The backend, which is a privileged domain then takes the page address
+and maps it into its own address space (in
+linux26/drivers/xen/blkback/interface.c:blkif_connect()):
+
+
+void blkif_connect(blkif_be_connect_t *connect)
+
+ ...
+ unsigned long shmem_frame = connect->shmem_frame;
+ ...
+
+ if ( (vma = get_vm_area(PAGE_SIZE, VM_IOREMAP)) == NULL )
+ {
+ connect->status = BLKIF_BE_STATUS_OUT_OF_MEMORY;
+ return;
+ }
+
+ prot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED);
+ error = direct_remap_area_pages(&init_mm, VMALLOC_VMADDR(vma->addr),
+ shmem_frame<<PAGE_SHIFT, PAGE_SIZE,
+ prot, domid);
+
+ ...
+
+ blkif->blk_ring_base = (blkif_ring_t *)vma->addr
+}}}
+
+The machine address of the page is passed in the shmem_frame field of
+the connect message. This is then mapped into the virtual address
+space of the backend domain, and saved in the blkif structure
+representing this particular backend connection.
+
+NOTE: New mechanisms will be added very shortly to allow domains to
+explicitly grant access to their pages to other domains. This "grant
+table" support is in the process of being added to the tree, and will
+change the way a shared page is set up. In particular, it will remove
+the need of the remapping domain to be privileged.
+
+Sending data across shared rings:
+
+Shared rings avoid the potential for write interference between
+domains in a very cunning way. A ring is partitioned into a request
+and a response region, and domains only work within their own space.
+This can be thought of as a double producer-consumer ring -- the ring
+is described by four pointers into a circular buffer of fixed-size
+records. Pointers may only advance, and may not pass one another.
+
+
+ rsp_cons----+
+ V
+ +----+----+----+----+----+----+----+
+ | | | free |RSP1|RSP2|
+ +----+----+----+----+----+----+----+
+ req_prod->| | --------> |RSP3|
+ +----+ +----+
+ |REQ8| | |<-rsp_prod
+ +----+ +----+
+ |REQ7| | |
+ +----+ +----+
+ |REQ6| <-------- | |
+ +----+----+----+----+----+----+----+
+ |REQ5|REQ4| free | | |
+ +----+----+----+----+----+----+----+
+ req_cons---------^
+
+
+
+By adopting the convention that every request will receive a response,
+not all four pointers need be shared and flow control on the ring
+becomes very easy to manage. Each domain manages its own
+consumer pointer, and the two producer pointers are visible to both (Xen/include/hypervisor-ifs/io/blkif.h):
+
+
+
+/* NB. Ring size must be small enough for sizeof(blkif_ring_t) <=PAGE_SIZE.*/
+ #define BLKIF_RING_SIZE 64
+
+ ...
+
+/*
+ * We use a special capitalised type name because it is _essential_ that all
+ * arithmetic on indexes is done on an integer type of the correct size.
+ */
+typedef u32 BLKIF_RING_IDX;
+
+/*
+ * Ring indexes are 'free running'. That is, they are not stored modulo the
+ * size of the ring buffer. The following macro converts a free-running counter
+ * into a value that can directly index a ring-buffer array.
+ */
+#define MASK_BLKIF_IDX(_i) ((_i)&(BLKIF_RING_SIZE-1))
+
+typedef struct {
+ BLKIF_RING_IDX req_prod; /* 0: Request producer. Updated by front-end. */
+ BLKIF_RING_IDX resp_prod; /* 4: Response producer. Updated by back-end. */
+ union { /* 8 */
+ blkif_request_t req;
+ blkif_response_t resp;
+ } PACKED ring[BLKIF_RING_SIZE];
+} PACKED blkif_ring_t;
+
+
+
+As shown in the diagram above, the rules for using a shared memory
+ring are simple.
+
+ 1. A ring is full when a domain's producer and consumer pointers are
+ equal (e.g. req_prod == resp_cons). In this situation, the
+ consumer pointer must be advanced. Furthermore, if the consumer
+ pointer is equal to the other domain's producer pointer,
+ (e.g. resp_cons = resp_prod), then the other domain has all the
+ buffers.
+
+2. Producer pointers point to the next buffer that will be written to.
+ (So blk_ring[MASK_BLKIF_IDX(req_prod)] should not be consumed.)
+
+3. Consumer pointers point to a valid message, so long as they are not
+ equal to the associated producer pointer.
+
+4. A domain should only ever write to the message pointed
+ to by its producer index, and read from the message at it's
+ consumer. More generally, the domain may be thought of to have
+ exclusive access to the messages between its consumer and producer,
+ and should absolutely not read or write outside this region.
+
+In general, drivers keep a private copy of their producer pointer and
+then set the shared version when they are ready for the other end to
+process a set of messages. Additionally, it is worth paying attention
+to the use of memory barriers (rmb/wmb) in the code, to ensure that
+rings that are shared across processors behave as expected.
+
+==== Structure of the Blkif Drivers ====
+
+Now that the communications primitives have been discussed, I'll
+quickly cover the general structure of the blkif driver. This is
+intended to give a high-level idea of what is going on, in an effort
+to make reading the code a more approachable task.
+
+There are three key software components that are involved in the blkif
+drivers (not counting Xen itself). The frontend and backend driver,
+and Xend, which coordinates their initial connection. Xend may also
+be involved in control-channel signalling in some cases after startup,
+for instance to manage reconnection if the backend is restarted.
+
+===== Frontend Driver Structure =====
+
+The frontend domain uses a single event channel and a shared memory
+ring to trade control messages with the backend. These are both setup
+during domain startup, which will be discussed shortly. The shared
+memory ring is called blkif_ring, and the private ring indexes are
+resp_cons, and req_prod. The ring is protected by blkif_io_lock.
+Additionally, the frontend keeps a list of outstanding requests in
+rec_ring[]. These are uniquely identified by a guest-local id number,
+which is associated with each request sent to the backend, and
+returned with the matching responses. Information about the actual
+disks are stored in major_info[], of which only the first nr_vbds
+entries are valid. Finally, the global 'recovery' indicates that the
+connection between the backend and frontend drivers has been broken
+(possibly due to a backend driver crash) and that the frontend is in
+recovery mode, in which case it will attempt to reconnect and reissue
+outstanding requests.
+
+The frontend driver is single-threaded and after setup is entered only
+through three points: (1) read/write requests from the XenLinux guest
+that it is a part of, (2) interrupts from the backend driver on its
+event channel (blkif_int()), and (3) control messages from Xend
+(blkif_ctrlif_rx).
+
+===== Backend Driver Structure =====
+
+The backend driver is slightly more complex as it must manage any
+number of concurrent frontend connections. For each domain it
+manages, the backend driver maintains a blkif structure, which
+describes all the connection and disk information associated with that
+particular domain. This structure is associated with the interrupt
+registration, and allows the backend driver to have immediate context
+when it takes a notification from some domain.
+
+All of the blkif structures are stored in a hash table (blkif_hash),
+which is indexed by a hash of the domain id, and a "handle", really a
+per-domain blkif identifier, in case it wants to have multiple connections.
+
+The per-connection blkif structure is of type blkif_t. It contains
+all of the communication details (event channel, irq, shared memory
+ring and indexes), and blk_ring_lock, which is the backend mutex on
+the shared ring. The structure also contains vbd_rb, which is a
+red-black tree, containing an entry for each device/partition that is
+assigned to that domain. This structure is filled by xend passing
+disk information to the backend at startup, and is protected by
+vbd_lock. Finally, the blkif struct contains a status field, which
+describes the state of the connection.
+
+The backend driver spawns a kernel thread at startup
+(blkio_schedule()), which handles requests to and from the actual disk
+device drivers. This scheduler thread maintains a list of blkif
+structures that have pending requests, and services them round-robin
+with a maximum per-round request limit. blkifs are added to the list
+in the interrupt handler (blkif_be_int()) using
+add_to_blkdev_list_tail(), and removed in the scheduler loop after
+calling do_block_io_op(), which processes a batch of requests. The
+scheduler thread is explicitly activated at several points in the code
+using maybe_trigger_blkio_schedule().
+
+Pending requests between the backend driver and the physical device
+drivers use another ring, pending_ring. Requests are placed in this
+ring in the scheduler thread and issued to the device. A completion
+callback, end_block_io_op, indicates that requests have been serviced
+and generates a response on the appropriate blkif ring. pending
+reqs[] stores a list of outstanding requests with the physical drivers.
+
+So, control entries to the backend are (1) the blkio scheduler thread,
+which sends requests to the real device drivers, (2) end_block_io_op,
+which is called as serviced requests complete, (3) blkif_be_int()
+handles notifications from the frontend drivers in other domains, and
+(4) blkif_ctrlif_rx() handles control messages from xend.
+
+==== Driver Startup ====
+
+Prior to starting a new guest using the frontend driver, the backend
+will have been started in a privileged domain. The backend
+initialisation code initialises all of its data structures, such as
+the blkif hash table, and starts the scheduler thread as a kernel
+thread. It then sends a driver status up message to let xend know it
+is ready to take frontend connections.
+
+When a new domain that uses the blkif frontend driver is started,
+there are a series of interactions between it, xend, and the specified
+backend driver. These interactions are as follows:
+
+The domain configuration given to xend will specify the backend domain
+and disks that the new guest is to use. Prior to actually running the
+domain, xend and the backend driver interact to setup the initial
+blkif record in the backend.
+
+(1) Xend sends a BLKIF_BE_CREATE message to backend.
+
+ Backend does blkif_create(), having been passed FE domid and handle.
+ It creates and initialises a new blkif struct, and puts it in the
+ hash table.
+ It then returns a STATUS_OK response to xend.
+
+(2) Xend sends a BLKIF_BE_VBD_CREATE message to the backend.
+
+ Backend adds a vbd entry in the red-black tree for the
+ specified (dom, handle) blkif entry.
+ Sends a STATUS_OK response.
+
+(3) Xend sends a BLKIF_BE_VBD_GROW message to the backend.
+
+ Backend takes the physical device information passed in the
+ message and assigns them to the newly created vbd struct.
+
+(2) and (3) repeat as any additional devices are added to the domain.
+
+At this point, the backend has enough state to allow the frontend
+domain to start. The domain is run, and eventually gets to the
+frontend driver initialisation code. After setting up the frontend
+data structures, this code continues the communications with xend and
+the backend to negotiate a connection:
+
+(4) Frontend sends Xend a BLKIF_FE_DRIVER_STATUS_CHANGED message.
+
+ This message tells xend that the driver is up. The init function
+ now spin-waits until driver setup is complete in order to prevent
+ Linux from attempting to boot before the disks are connected.
+
+(5) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
+
+ This message specifies that the interface is now disconnected
+ (instead of closed).
+ The domain updates it's state, and allocates the shared blk_ring
+ page. Next,
+
+(6) Frontend sends Xend a BLKIF_INTERFACE_CONNECT message
+
+ This message specifies the domain and handle, and includes the
+ address of the newly created page.
+
+(7) Xend sends the backend a BLKIF_BE_CONNECT message
+
+ The backend fills in the blkif connection information, maps the
+ shared page, and binds an irq to the event channel.
+
+(8) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
+
+ This message takes the frontend driver to a CONNECTED state, at
+ which point it binds an irq to the event channel and calls
+ xlvbd_init to initialise the individual block devices.
+
+The frontend Linux is stall spin waiting at this point, until all of
+the disks have been probed. Messaging now is directly between the
+front and backend domain using the new shared ring and event channel.
+
+(9) The frontend sends a BLKIF_OP_PROBE directly to the backend.
+
+ This message includes a reference to an additional page, that the
+ backend can use for it's reply. The backend responds with an array
+ of the domains disks (as vdisk_t structs) on the provided page.
+
+The frontend now initialises each disk, calling xlvbd_init_device()
+for each one.
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
+ <title>Xen Configuration Syntax</title>
+</head>
+<body>
+<center>
+<h1>Xen Configuration Syntax</h1>
+<br>
+<!-- Version 0.1<br>2004 June 21<br> -->
+Version 0.2<br>2004 July 19<br>
+</center>
+
+<h1>Xen Configuration</h1>
+The Xen virtual machine creation tools provide command-line interfaces and
+HTTP interfaces to creating virtual machines. Underneath all these interfaces
+virtual machine configuration data is represented in a common configuration syntax
+called SXP.
+
+The SXP syntax is s-expressions (sxprs), a simple bracketed abstract syntax.
+Python lists are used to represent its parsed form, with a support
+api providing access to fields and values (class xen.xend.sxp).
+
+<h1>SXP syntax</h1>
+<p>A general s-expression has the syntax:
+<code><pre>
+s-exp = '(' s-exp* ')' | atom | string
+</pre></code>
+Where an <code>atom</code> is an unquoted string, such as fred or /domain/0.
+A <code>string</code> is a quoted string, supporting the usual escape sequences.
+Strings support single or double quotes: 'fred 1' or "fred 2" are both accepted.
+The characters ()[]<>{} are separators.
+
+<p>An <code>element</code> is an s-expression representing data similar to XML.
+It has the form:
+<code><pre>
+element = '(' name attributes? value* ')'
+name = atom
+attributes = '(' '@' attribute* ')'
+attribute = '(' attrname attrval ')'
+attrname = atom
+attrval = atom | string
+value = element | atom | string
+</pre></code>
+The <code>name</code> is the element name (roughly indentifying its type).
+The <code>attributes</code> is a list of attribute-values.
+We usually prefer to avoid using attributes, and use sub-elements instead.
+As in XML, any element may have the attribute <code>id</code> to give it an identifier
+for later reference.
+
+<h1>VM configuration</h1>
+A vm configuration is a single SXP vm element, with subelements for
+vm parameters and devices. The supported elements and their fields
+are listed below.
+
+<h2>(vm) element</h2>
+The top-level element, a virtual machine configuration.
+<ul>
+ <li>name: string, required. Domain name.
+ <li>id: int, optional, default generated. Domain unique id.
+ <li>memory: int, required. Domain memory in MB.
+ <li>maxmem: int, optional. Maximum domain memory in MB.
+ <li>cpu: int, optional. Cpu to run on.
+ <li>cpu_weight, float, optional, default 1. Cpu weight - controls share of CPU.
+ <li>image: linux | netbsd | ..., required. Domain image (OS-specific element).
+ <li>backend: any backend device type, optional, default none.
+ <li>device: any device type, optional, repeats. Device.
+ <li>restart: string, optional, default onreboot. Restart mode, one of
+ <ul><li>onreboot: restart the domain when it exits with code reboot.
+ <li>always: always restart the domain when it exits.
+ <li>never: never restart the domain.
+ </ul>
+ <li>console: int, optional, default 9600 + domain id. Console port.
+</ul>
+
+<h2>(image (linux)) element</h2>
+Defines a linux kernel image and its command-line parameters.
+<ul>
+ <li>kernel: string, required. Kernel image file (absolute path).
+ <li>root: string, optional. Root device.
+ <li>ip: string, optional. IP address specifier.
+ <li>ramdisk: string, optional, default none. Ramdisk file (absolute path).
+ <li>args: string, optional. Extra kernel args.
+</ul>
+
+<h2>(image (netbsd)) element</h2>
+Defines a netbsd kernel image and its command-line parameters.
+<ul>
+ <li>kernel: string, required. Kernel image file.
+ <li>root: string, optional. Root device.
+ <li>ip: string, optional. IP address specifier.
+ <li>ramdisk: string, optional, default none. Ramdisk file.
+ <li>args: string, optional. Extra kernel args.
+</ul>
+
+<h2>(backend (blkif)) element</h2>
+The vm is a block device backend.
+The vm can have pci devices configured.
+
+<h2>(backend (netif)) element</h2>
+The vm is a net device backend.
+
+<h2>(device (vif)) element</h2>
+Defines a virtual network interface.
+<ul>
+ <li>mac: string, required. Interface MAC address.
+ <li>bridge: string, optional, default system-dependent. Bridge to connect to.
+ <li>script: string, optional, default system-dependent. Vif script to use
+ when bringing the interface up or down.
+ <li>ip: IP address, optional, no default. May be repeated. An IP address
+ or CIDR-format subnet the vif may use.
+ <li>backend: domain name or id, optional, default 0.
+ Defines the domain to use as the backend for the interface.
+</ul>
+
+<h2>(device (vbd)) element</h2>
+Defines a virtual block device.
+<ul>
+ <li>uname: string, required. Virtual block device id, e.g phys:hda1.
+ <li>dev: string, required. Device file name in domain, e.g. xda1.
+ <li>mode: string, optional, default r. Read-write mode: r | rw | w.
+ <li>backend: domain name or id, optional, default 0.
+ Defines the domain to use as the backend for the device.
+</ul>
+The uname field defines the device being exported from the block device
+controller. The dev field defines the device name the vm will see.
+The device is read-only unless the mode contains w.
+
+<h2>(device (pci)) element</h2>
+Defines a pci device.
+<ul>
+ <li>bus: int, required. PCI bus id.
+ <li>dev: int, required. PCI dev id.
+ <li>func: int, required. PCI func id.
+</ul>
+The bus, dev or func may be given in hex,
+e.g. 0xff. With no leading 0x they are interpreted as decimal.
+
+<h2>(vnet) element</h2>
+Defines the virtual networks associated with vifs (may go away soon).
+Contains a list of vif elements:
+<ul>
+ <li>id: id of the vif being configured.
+ <li>vnet: id of vnet the vif is assigned to.
+</ul>
+
+<h1>Examples</h1>
+<p> A vm with 64 MB memory, root on /dev/xda1 (mapped from /dev/hda1),
+one vif with default MAC.
+<code><pre>
+(vm
+ (name xendom1)
+ (memory 64)
+ (image
+ (linux
+ (kernel /boot/vmlinuz-2.4.26-xen)
+ (ip ::::xendom1:eth0:dhcp)
+ (root /dev/xda1)
+ (args 'rw fastboot 4')
+ )
+ )
+ (device (vif))
+ (device (vbd (uname phy:hda1) (dev xda1) (mode w)))
+)
+</pre></code>
+
+<p>A vm with 64 MB memory, NFS root, and 2 vifs on separate vnets.
+<code><pre>
+(vm
+ (name xendom2)
+ (memory 64)
+ # Define a linux image.
+ (image
+ (linux
+ (kernel "/boot/vmlinuz-2.4.26-xen")
+ (ip "::::xendom2:eth0:dhcp")
+ (root "/dev/nfs")
+ (args "rw fastboot nfsroot=15.144.25.79:/opt/xen/xendom2 4")
+ )
+ )
+ # Define some vifs, with ids for use later.
+ (device (vif (@ (id vif1)) (mac aa:00:00:00:00:12)))
+ (device (vif (@ (id vif2)) (mac aa:00:00:00:10:12)))
+
+ # Configure vnets. Refer to vifs by id.
+ (vnet (vif (id vif1) (vnet 1))
+ (vif (id vif2) (vnet 2)))
+
+)
+</pre></code>
+
+</body>
+</html>
--- /dev/null
+\documentclass[11pt,twoside,final,openright]{xenstyle}
+\usepackage{a4,graphicx,setspace}
+\setstretch{1.15}
+
+\begin{document}
+
+% TITLE PAGE
+\pagestyle{empty}
+\begin{center}
+\vspace*{\fill}
+\includegraphics{figs/xenlogo.eps}
+\vfill
+\vfill
+\vfill
+\begin{tabular}{l}
+{\Huge \bf Interface manual} \\[4mm]
+{\huge Xen v2.0 for x86} \\[80mm]
+
+{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
+{\Large University of Cambridge, UK} \\[20mm]
+{\large Last updated on 11th March, 2004}
+\end{tabular}
+\vfill
+\end{center}
+\cleardoublepage
+
+% TABLE OF CONTENTS
+\pagestyle{plain}
+\pagenumbering{roman}
+{ \parskip 0pt plus 1pt
+ \tableofcontents }
+\cleardoublepage
+
+% PREPARE FOR MAIN TEXT
+\pagenumbering{arabic}
+\raggedbottom
+\widowpenalty=10000
+\clubpenalty=10000
+\parindent=0pt
+\renewcommand{\topfraction}{.8}
+\renewcommand{\bottomfraction}{.8}
+\renewcommand{\textfraction}{.2}
+\renewcommand{\floatpagefraction}{.8}
+\setstretch{1.15}
+
+\chapter{Introduction}
+Xen allows the hardware resouces of a machine to be virtualized and
+dynamically partitioned such as to allow multiple different 'guest'
+operating system images to be run simultaneously.
+
+Virtualizing the machine in this manner provides flexibility allowing
+different users to choose their preferred operating system (Windows,
+Linux, NetBSD, or a custom operating system). Furthermore, Xen provides
+secure partitioning between these 'domains', and enables better resource
+accounting and QoS isolation than can be achieved with a conventional
+operating system.
+
+The hypervisor runs directly on server hardware and dynamically partitions
+it between a number of {\it domains}, each of which hosts an instance
+of a {\it guest operating system}. The hypervisor provides just enough
+abstraction of the machine to allow effective isolation and resource
+management between these domains.
+
+Xen essentially takes a virtual machine approach as pioneered by IBM
+VM/370. However, unlike VM/370 or more recent efforts such as VMWare
+and Virtual PC, Xen doesn not attempt to completely virtualize the
+underlying hardware. Instead parts of the hosted guest operating
+systems are modified to work with the hypervisor; the operating system
+is effectively ported to a new target architecture, typically
+requiring changes in just the machine-dependent code. The user-level
+API is unchanged, thus existing binaries and operating system
+distributions can work unmodified.
+
+In addition to exporting virtualized instances of CPU, memory, network and
+block devicees, Xen exposes a control interface to set how these resources
+are shared between the running domains. The control interface is privileged
+and may only be accessed by one particular virtual machine: {\it domain0}.
+This domain is a required part of any Xen-base server and runs the application
+software that manages the control-plane aspects of the platform. Running the
+control software in {\it domain0}, distinct from the hypervisor itself, allows
+the Xen framework to separate the notions of {\it mechanism} and {\it policy}
+within the system.
+
+
+\chapter{CPU state}
+
+All privileged state must be handled by Xen. The guest OS has no
+direct access to CR3 and is not permitted to update privileged bits in
+EFLAGS.
+
+\chapter{Exceptions}
+The IDT is virtualised by submitting a virtual 'trap
+table' to Xen. Most trap handlers are identical to native x86
+handlers. The page-fault handler is a noteable exception.
+
+\chapter{Interrupts and events}
+Interrupts are virtualized by mapping them to events, which are delivered
+asynchronously to the target domain. A guest OS can map these events onto
+its standard interrupt dispatch mechanisms, such as a simple vectoring
+scheme. Each physical interrupt source controlled by the hypervisor, including
+network devices, disks, or the timer subsystem, is responsible for identifying
+the target for an incoming interrupt and sending an event to that domain.
+
+This demultiplexing mechanism also provides a device-specific mechanism for
+event coalescing or hold-off. For example, a guest OS may request to only
+actually receive an event after {\it n} packets are queued ready for delivery
+to it, {\it t} nanoseconds after the first packet arrived (which ever is true
+first). This allows latency and throughput requirements to be addressed on a
+domain-specific basis.
+
+\chapter{Time}
+Guest operating systems need to be aware of the passage of real time and their
+own ``virtual time'', i.e. the time they have been executing. Furthermore, a
+notion of time is required in the hypervisor itself for scheduling and the
+activities that relate to it. To this end the hypervisor provides for notions
+of time: cycle counter time, system time, wall clock time, domain virtual
+time.
+
+
+\section{Cycle counter time}
+This provides the finest-grained, free-running time reference, with the
+approximate frequency being publicly accessible. The cycle counter time is
+used to accurately extrapolate the other time references. On SMP machines
+it is currently assumed that the cycle counter time is synchronised between
+CPUs. The current x86-based implementation achieves this within inter-CPU
+communication latencies.
+
+\section{System time}
+This is a 64-bit value containing the nanoseconds elapsed since boot
+time. Unlike cycle counter time, system time accurately reflects the
+passage of real time, i.e. it is adjusted several times a second for timer
+drift. This is done by running an NTP client in {\it domain0} on behalf of
+the machine, feeding updates to the hypervisor. Intermediate values can be
+extrapolated using the cycle counter.
+
+\section{Wall clock time}
+This is the actual ``time of day'' Unix style struct timeval (i.e. seconds and
+microseconds since 1 January 1970, adjusted by leap seconds etc.). Again, an
+NTP client hosted by {\it domain0} can help maintain this value. To guest
+operating systems this value will be reported instead of the hardware RTC
+clock value and they can use the system time and cycle counter times to start
+and remain perfectly in time.
+
+
+\section{Domain virtual time}
+This progresses at the same pace as cycle counter time, but only while a
+domain is executing. It stops while a domain is de-scheduled. Therefore the
+share of the CPU that a domain receives is indicated by the rate at which
+its domain virtual time increases, relative to the rate at which cycle
+counter time does so.
+
+\section{Time interface}
+Xen exports some timestamps to guest operating systems through their shared
+info page. Timestamps are provided for system time and wall-clock time. Xen
+also provides the cycle counter values at the time of the last update
+allowing guests to calculate the current values. The cpu frequency and a
+scaling factor are provided for guests to convert cycle counter values to
+real time. Since all time stamps need to be updated and read
+\emph{atomically} two version numbers are also stored in the shared info
+page.
+
+Xen will ensure that the time stamps are updated frequently enough to avoid
+an overflow of the cycle counter values. A guest can check if its notion of
+time is up-to-date by comparing the version numbers.
+
+\section{Timer events}
+
+Xen maintains a periodic timer (currently with a 10ms period) which sends a
+timer event to the currently executing domain. This allows Guest OSes to
+keep track of the passing of time when executing. The scheduler also
+arranges for a newly activated domain to receive a timer event when
+scheduled so that the Guest OS can adjust to the passage of time while it
+has been inactive.
+
+In addition, Xen exports a hypercall interface to each domain which allows
+them to request a timer event sent to them at the specified system
+time. Guest OSes may use this timer to implement timeout values when they
+block.
+
+\chapter{Memory}
+
+The hypervisor is responsible for providing memory to each of the
+domains running over it. However, the Xen hypervisor's duty is
+restricted to managing physical memory and to policying page table
+updates. All other memory management functions are handled
+externally. Start-of-day issues such as building initial page tables
+for a domain, loading its kernel image and so on are done by the {\it
+domain builder} running in user-space in {\it domain0}. Paging to
+disk and swapping is handled by the guest operating systems
+themselves, if they need it.
+
+On a Xen-based system, the hypervisor itself runs in {\it ring 0}. It
+has full access to the physical memory available in the system and is
+responsible for allocating portions of it to the domains. Guest
+operating systems run in and use {\it rings 1}, {\it 2} and {\it 3} as
+they see fit, aside from the fact that segmentation is used to prevent
+the guest OS from accessing a portion of the linear address space that
+is reserved for use by the hypervisor. This approach allows
+transitions between the guest OS and hypervisor without flushing the
+TLB. We expect most guest operating systems will use ring 1 for their
+own operation and place applications (if they support such a notion)
+in ring 3.
+
+\section{Physical Memory Allocation}
+The hypervisor reserves a small fixed portion of physical memory at
+system boot time. This special memory region is located at the
+beginning of physical memory and is mapped at the very top of every
+virtual address space.
+
+Any physical memory that is not used directly by the hypervisor is divided into
+pages and is available for allocation to domains. The hypervisor tracks which
+pages are free and which pages have been allocated to each domain. When a new
+domain is initialized, the hypervisor allocates it pages drawn from the free
+list. The amount of memory required by the domain is passed to the hypervisor
+as one of the parameters for new domain initialization by the domain builder.
+
+Domains can never be allocated further memory beyond that which was
+requested for them on initialization. However, a domain can return
+pages to the hypervisor if it discovers that its memory requirements
+have diminished.
+
+% put reasons for why pages might be returned here.
+\section{Page Table Updates}
+In addition to managing physical memory allocation, the hypervisor is also in
+charge of performing page table updates on behalf of the domains. This is
+neccessary to prevent domains from adding arbitrary mappings to their page
+tables or introducing mappings to other's page tables.
+
+\section{Writabel Page Tables}
+A domain can also request write access to its page tables. In this
+mode, Xen notes write attempts to page table pages and makes the page
+temporarily writable. In-use page table pages are also disconnect
+from the page directory. The domain can now update entries in these
+page table pages without the assistance of Xen. As soon as the
+writabel page table pages get used as page table pages, Xen makes the
+pages read-only again and revalidates the entries in the pages.
+
+\section{Segment Descriptor Tables}
+
+On boot a guest is supplied with a default GDT, which is {\em not}
+taken from its own memory allocation. If the guest wishes to use other
+than the default `flat' ring-1 and ring-3 segments that this default
+table provides, it must register a custom GDT and/or LDT with Xen,
+allocated from its own memory.
+
+int {\bf set\_gdt}(unsigned long *{\em frame\_list}, int {\em entries})
+
+{\em frame\_list}: An array of up to 16 page frames within which the
+GDT resides. Any frame registered as a GDT frame may only be mapped
+read-only within the guest's address space (e.g., no writable
+mappings, no use as a page-table page, and so on).
+
+{\em entries}: The number of descriptor-entry slots in the GDT. Note
+that the table must be large enough to contain Xen's reserved entries;
+thus we must have '{\em entries $>$ LAST\_RESERVED\_GDT\_ENTRY}'.
+Note also that, after registering the GDT, slots {\em FIRST\_} through
+{\em LAST\_RESERVED\_GDT\_ENTRY} are no longer usable by the guest and
+may be overwritten by Xen.
+
+\section{Pseudo-Physical Memory}
+The usual problem of external fragmentation means that a domain is
+unlikely to receive a contiguous stretch of physical memory. However,
+most guest operating systems do not have built-in support for
+operating in a fragmented physical address space e.g. Linux has to
+have a one-to-one mapping for its physical memory. There a notion of
+{\it pseudo physical memory} is introdouced. Xen maintains a {\it
+real physical} to {\it pseudo physical} mapping which can be consulted
+by every domain. Additionally, at its start of day, a domain is
+supplied a {\it pseudo physical} to {\it real physical} mapping which
+it needs to keep updated itself. From that moment onwards {\it pseudo
+physical} addresses are used instead of discontiguous {\it real
+physical} addresses. Thus, the rest of the guest OS code has an
+impression of operating in a contiguous address space. Guest OS page
+tables contain real physical addresses. Mapping {\it pseudo physical}
+to {\it real physical} addresses is needed on page table updates and
+also on remapping memory regions with the guest OS.
+
+
+
+\chapter{Network I/O}
+
+Virtual network device services are provided by shared memory
+communications with a `backend' domain. From the point of view of
+other domains, the backend may be viewed as a virtual ethernet switch
+element with each domain having one or more virtual network interfaces
+connected to it.
+
+\section{Backend Packet Handling}
+The backend driver is responsible primarily for {\it data-path} operations.
+In terms of networking this means packet transmission and reception.
+
+On the transmission side, the backend needs to perform two key actions:
+\begin{itemize}
+\item {\tt Validation:} A domain may only be allowed to emit packets
+matching a certain specification; for example, ones in which the
+source IP address matches one assigned to the virtual interface over
+which it is sent. The backend would be responsible for ensuring any
+such requirements are met, either by checking or by stamping outgoing
+packets with prescribed values for certain fields.
+
+Validation functions can be configured using standard firewall rules
+(i.e. IP Tables, in the case of Linux).
+
+\item {\tt Scheduling:} Since a number of domains can share a single
+``real'' network interface, the hypervisor must mediate access when
+several domains each have packets queued for transmission. Of course,
+this general scheduling function subsumes basic shaping or
+rate-limiting schemes.
+
+\item {\tt Logging and Accounting:} The hypervisor can be configured
+with classifier rules that control how packets are accounted or
+logged. For example, {\it domain0} could request that it receives a
+log message or copy of the packet whenever another domain attempts to
+send a TCP packet containg a SYN.
+\end{itemize}
+
+On the recive side, the backend's role is relatively straightforward:
+once a packet is received, it just needs to determine the virtual interface(s)
+to which it must be delivered and deliver it via page-flipping.
+
+
+\section{Data Transfer}
+
+Each virtual interface uses two ``descriptor rings'', one for transmit,
+the other for receive. Each descriptor identifies a block of contiguous
+physical memory allocated to the domain. There are four cases:
+
+\begin{itemize}
+
+\item The transmit ring carries packets to transmit from the domain to the
+hypervisor.
+
+\item The return path of the transmit ring carries ``empty'' descriptors
+indicating that the contents have been transmitted and the memory can be
+re-used.
+
+\item The receive ring carries empty descriptors from the domain to the
+hypervisor; these provide storage space for that domain's received packets.
+
+\item The return path of the receive ring carries packets that have been
+received.
+\end{itemize}
+
+Real physical addresses are used throughout, with the domain performing
+translation from pseudo-physical addresses if that is necessary.
+
+If a domain does not keep its receive ring stocked with empty buffers then
+packets destined to it may be dropped. This provides some defense against
+receiver-livelock problems because an overload domain will cease to receive
+further data. Similarly, on the transmit path, it provides the application
+with feedback on the rate at which packets are able to leave the system.
+
+Synchronization between the hypervisor and the domain is achieved using
+counters held in shared memory that is accessible to both. Each ring has
+associated producer and consumer indices indicating the area in the ring
+that holds descriptors that contain data. After receiving {\it n} packets
+or {\t nanoseconds} after receiving the first packet, the hypervisor sends
+an event to the domain.
+
+\chapter{Block I/O}
+
+\section{Virtual Block Devices (VBDs)}
+
+All guest OS disk access goes through the VBD interface. The VBD
+interface provides the administrator with the ability to selectively
+grant domains access to portions of block storage devices visible to
+the the block backend device (usually domain 0).
+
+VBDs can literally be backed by any block device accessible to the
+backend domain, including network-based block devices (iSCSI, *NBD,
+etc), loopback devices and LVM / MD devices.
+
+Old (Xen 1.2) virtual disks are not supported under Xen 2.0, since
+similar functionality can be achieved using the (more advanced) LVM
+system, which is already in widespread use.
+
+\subsection{Data Transfer}
+Domains which have been granted access to a logical block device are permitted
+to read and write it by shared memory communications with the backend domain.
+
+In overview, the same style of descriptor-ring that is used for
+network packets is used here. Each domain has one ring that carries
+operation requests to the hypervisor and carries the results back
+again.
+
+Rather than copying data, the backend simply maps the domain's buffers
+in order to enable direct DMA to them. The act of mapping the buffers
+also increases the reference counts of the underlying pages, so that
+the unprivileged domain cannot try to return them to the hypervisor,
+install them as page tables, or any other unsafe behaviour.
+%block API here
+
+\chapter{Privileged operations}
+{\it Domain0} is responsible for building all other domains on the server
+and providing control interfaces for managing scheduling, networking, and
+blocks.
+
+\chapter{CPU Scheduler}
+
+Xen offers a uniform API for CPU schedulers. It is possible to choose
+from a number of schedulers at boot and it should be easy to add more.
+
+\paragraph*{Note: SMP host support}
+Xen has always supported SMP host systems. Domains are statically assigned to
+CPUs, either at creation time or when manually pinning to a particular CPU.
+The current schedulers then run locally on each CPU to decide which of the
+assigned domains should be run there.
+
+\section{Standard Schedulers}
+
+These BVT, Atropos and Round Robin schedulers are part of the normal
+Xen distribution. BVT provides proportional fair shares of the CPU to
+the running domains. Atropos can be used to reserve absolute shares
+of the CPU for each domain. Round-robin is provided as an example of
+Xen's internal scheduler API.
+
+More information on the characteristics and use of these schedulers is
+available in { \tt Sched-HOWTO.txt }.
+
+\section{Scheduling API}
+
+The scheduling API is used by both the schedulers described above and should
+also be used by any new schedulers. It provides a generic interface and also
+implements much of the ``boilerplate'' code.
+
+Schedulers conforming to this API are described by the following
+structure:
+
+\begin{verbatim}
+struct scheduler
+{
+ char *name; /* full name for this scheduler */
+ char *opt_name; /* option name for this scheduler */
+ unsigned int sched_id; /* ID for this scheduler */
+
+ int (*init_scheduler) ();
+ int (*alloc_task) (struct task_struct *);
+ void (*add_task) (struct task_struct *);
+ void (*free_task) (struct task_struct *);
+ void (*rem_task) (struct task_struct *);
+ void (*wake_up) (struct task_struct *);
+ void (*do_block) (struct task_struct *);
+ task_slice_t (*do_schedule) (s_time_t);
+ int (*control) (struct sched_ctl_cmd *);
+ int (*adjdom) (struct task_struct *,
+ struct sched_adjdom_cmd *);
+ s32 (*reschedule) (struct task_struct *);
+ void (*dump_settings) (void);
+ void (*dump_cpu_state) (int);
+ void (*dump_runq_el) (struct task_struct *);
+};
+\end{verbatim}
+
+The only method that {\em must} be implemented is
+{\tt do\_schedule()}. However, if there is not some implementation for the
+{\tt wake\_up()} method then waking tasks will not get put on the runqueue!
+
+The fields of the above structure are described in more detail below.
+
+\subsubsection{name}
+
+The name field should point to a descriptive ASCII string.
+
+\subsubsection{opt\_name}
+
+This field is the value of the {\tt sched=} boot-time option that will select
+this scheduler.
+
+\subsubsection{sched\_id}
+
+This is an integer that uniquely identifies this scheduler. There should be a
+macro corrsponding to this scheduler ID in {\tt <hypervisor-ifs/sched-if.h>}.
+
+\subsubsection{init\_scheduler}
+
+\paragraph*{Purpose}
+
+This is a function for performing any scheduler-specific initialisation. For
+instance, it might allocate memory for per-CPU scheduler data and initialise it
+appropriately.
+
+\paragraph*{Call environment}
+
+This function is called after the initialisation performed by the generic
+layer. The function is called exactly once, for the scheduler that has been
+selected.
+
+\paragraph*{Return values}
+
+This should return negative on failure --- this will cause an
+immediate panic and the system will fail to boot.
+
+\subsubsection{alloc\_task}
+
+\paragraph*{Purpose}
+Called when a {\tt task\_struct} is allocated by the generic scheduler
+layer. A particular scheduler implementation may use this method to
+allocate per-task data for this task. It may use the {\tt
+sched\_priv} pointer in the {\tt task\_struct} to point to this data.
+
+\paragraph*{Call environment}
+The generic layer guarantees that the {\tt sched\_priv} field will
+remain intact from the time this method is called until the task is
+deallocated (so long as the scheduler implementation does not change
+it explicitly!).
+
+\paragraph*{Return values}
+Negative on failure.
+
+\subsubsection{add\_task}
+
+\paragraph*{Purpose}
+
+Called when a task is initially added by the generic layer.
+
+\paragraph*{Call environment}
+
+The fields in the {\tt task\_struct} are now filled out and available for use.
+Schedulers should implement appropriate initialisation of any per-task private
+information in this method.
+
+\subsubsection{free\_task}
+
+\paragraph*{Purpose}
+
+Schedulers should free the space used by any associated private data
+structures.
+
+\paragraph*{Call environment}
+
+This is called when a {\tt task\_struct} is about to be deallocated.
+The generic layer will have done generic task removal operations and
+(if implemented) called the scheduler's {\tt rem\_task} method before
+this method is called.
+
+\subsubsection{rem\_task}
+
+\paragraph*{Purpose}
+
+This is called when a task is being removed from scheduling (but is
+not yet being freed).
+
+\subsubsection{wake\_up}
+
+\paragraph*{Purpose}
+
+Called when a task is woken up, this method should put the task on the runqueue
+(or do the scheduler-specific equivalent action).
+
+\paragraph*{Call environment}
+
+The task is already set to state RUNNING.
+
+\subsubsection{do\_block}
+
+\paragraph*{Purpose}
+
+This function is called when a task is blocked. This function should
+not remove the task from the runqueue.
+
+\paragraph*{Call environment}
+
+The EVENTS\_MASTER\_ENABLE\_BIT is already set and the task state changed to
+TASK\_INTERRUPTIBLE on entry to this method. A call to the {\tt
+ do\_schedule} method will be made after this method returns, in
+order to select the next task to run.
+
+\subsubsection{do\_schedule}
+
+This method must be implemented.
+
+\paragraph*{Purpose}
+
+The method is called each time a new task must be chosen for scheduling on the
+current CPU. The current time as passed as the single argument (the current
+task can be found using the {\tt current} macro).
+
+This method should select the next task to run on this CPU and set it's minimum
+time to run as well as returning the data described below.
+
+This method should also take the appropriate action if the previous
+task has blocked, e.g. removing it from the runqueue.
+
+\paragraph*{Call environment}
+
+The other fields in the {\tt task\_struct} are updated by the generic layer,
+which also performs all Xen-specific tasks and performs the actual task switch
+(unless the previous task has been chosen again).
+
+This method is called with the {\tt schedule\_lock} held for the current CPU
+and local interrupts disabled.
+
+\paragraph*{Return values}
+
+Must return a {\tt struct task\_slice} describing what task to run and how long
+for (at maximum).
+
+\subsubsection{control}
+
+\paragraph*{Purpose}
+
+This method is called for global scheduler control operations. It takes a
+pointer to a {\tt struct sched\_ctl\_cmd}, which it should either
+source data from or populate with data, depending on the value of the
+{\tt direction} field.
+
+\paragraph*{Call environment}
+
+The generic layer guarantees that when this method is called, the
+caller selected the correct scheduler ID, hence the scheduler's
+implementation does not need to sanity-check these parts of the call.
+
+\paragraph*{Return values}
+
+This function should return the value to be passed back to user space, hence it
+should either be 0 or an appropriate errno value.
+
+\subsubsection{sched\_adjdom}
+
+\paragraph*{Purpose}
+
+This method is called to adjust the scheduling parameters of a particular
+domain, or to query their current values. The function should check
+the {\tt direction} field of the {\tt sched\_adjdom\_cmd} it receives in
+order to determine which of these operations is being performed.
+
+\paragraph*{Call environment}
+
+The generic layer guarantees that the caller has specified the correct
+control interface version and scheduler ID and that the supplied {\tt
+task\_struct} will not be deallocated during the call (hence it is not
+necessary to {\tt get\_task\_struct}).
+
+\paragraph*{Return values}
+
+This function should return the value to be passed back to user space, hence it
+should either be 0 or an appropriate errno value.
+
+\subsubsection{reschedule}
+
+\paragraph*{Purpose}
+
+This method is called to determine if a reschedule is required as a result of a
+particular task.
+
+\paragraph*{Call environment}
+The generic layer will cause a reschedule if the current domain is the idle
+task or it has exceeded its minimum time slice before a reschedule. The
+generic layer guarantees that the task passed is not currently running but is
+on the runqueue.
+
+\paragraph*{Return values}
+
+Should return a mask of CPUs to cause a reschedule on.
+
+\subsubsection{dump\_settings}
+
+\paragraph*{Purpose}
+
+If implemented, this should dump any private global settings for this
+scheduler to the console.
+
+\paragraph*{Call environment}
+
+This function is called with interrupts enabled.
+
+\subsubsection{dump\_cpu\_state}
+
+\paragraph*{Purpose}
+
+This method should dump any private settings for the specified CPU.
+
+\paragraph*{Call environment}
+
+This function is called with interrupts disabled and the {\tt schedule\_lock}
+for the specified CPU held.
+
+\subsubsection{dump\_runq\_el}
+
+\paragraph*{Purpose}
+
+This method should dump any private settings for the specified task.
+
+\paragraph*{Call environment}
+
+This function is called with interrupts disabled and the {\tt schedule\_lock}
+for the task's CPU held.
+
+
+\chapter{Debugging}
+
+Xen provides tools for debugging both Xen and guest OSes. Currently, the
+Pervasive Debugger provides a GDB stub, which provides facilities for symbolic
+debugging of Xen itself and of OS kernels running on top of Xen. The Trace
+Buffer provides a lightweight means to log data about Xen's internal state and
+behaviour at runtime, for later analysis.
+
+\section{Pervasive Debugger}
+
+Information on using the pervasive debugger is available in pdb.txt.
+
+
+\section{Trace Buffer}
+
+The trace buffer provides a means to observe Xen's operation from domain 0.
+Trace events, inserted at key points in Xen's code, record data that can be
+read by the {\tt xentrace} tool. Recording these events has a low overhead
+and hence the trace buffer may be useful for debugging timing-sensitive
+behaviours.
+
+\subsection{Internal API}
+
+To use the trace buffer functionality from within Xen, you must {\tt \#include
+<xen/trace.h>}, which contains definitions related to the trace buffer. Trace
+events are inserted into the buffer using the {\tt TRACE\_xD} ({\tt x} = 0, 1,
+2, 3, 4 or 5) macros. These all take an event number, plus {\tt x} additional
+(32-bit) data as their arguments. For trace buffer-enabled builds of Xen these
+will insert the event ID and data into the trace buffer, along with the current
+value of the CPU cycle-counter. For builds without the trace buffer enabled,
+the macros expand to no-ops and thus can be left in place without incurring
+overheads.
+
+\subsection{Trace-enabled builds}
+
+By default, the trace buffer is enabled only in debug builds (i.e. {\tt NDEBUG}
+is not defined). It can be enabled separately by defining {\tt TRACE\_BUFFER},
+either in {\tt <xen/config.h>} or on the gcc command line.
+
+The size (in pages) of the per-CPU trace buffers can be specified using the
+{\tt tbuf\_size=n } boot parameter to Xen. If the size is set to 0, the trace
+buffers will be disabled.
+
+\subsection{Dumping trace data}
+
+When running a trace buffer build of Xen, trace data are written continuously
+into the buffer data areas, with newer data overwriting older data. This data
+can be captured using the {\tt xentrace} program in Domain 0.
+
+The {\tt xentrace} tool uses {\tt /dev/mem} in domain 0 to map the trace
+buffers into its address space. It then periodically polls all the buffers for
+new data, dumping out any new records from each buffer in turn. As a result,
+for machines with multiple (logical) CPUs, the trace buffer output will not be
+in overall chronological order.
+
+The output from {\tt xentrace} can be post-processed using {\tt
+xentrace\_cpusplit} (used to split trace data out into per-cpu log files) and
+{\tt xentrace\_format} (used to pretty-print trace data). For the predefined
+trace points, there is an example format file in {\tt tools/xentrace/formats }.
+
+For more information, see the manual pages for {\tt xentrace}, {\tt
+xentrace\_format} and {\tt xentrace\_cpusplit}.
+
+
+\chapter{Hypervisor calls}
+
+\section{ set\_trap\_table(trap\_info\_t *table)}
+
+Install trap handler table.
+
+\section{ mmu\_update(mmu\_update\_t *req, int count, int *success\_count)}
+Update the page table for the domain. Updates can be batched.
+success\_count will be updated to report the number of successfull
+updates. The update types are:
+
+{\it MMU\_NORMAL\_PT\_UPDATE}:
+
+{\it MMU\_MACHPHYS\_UPDATE}:
+
+{\it MMU\_EXTENDED\_COMMAND}:
+
+\section{ set\_gdt(unsigned long *frame\_list, int entries)}
+Set the global descriptor table - virtualization for lgdt.
+
+\section{ stack\_switch(unsigned long ss, unsigned long esp)}
+Request context switch from hypervisor.
+
+\section{ set\_callbacks(unsigned long event\_selector, unsigned long event\_address,
+ unsigned long failsafe\_selector, unsigned
+ long failsafe\_address) } Register OS event processing routine. In
+ Linux both the event\_selector and failsafe\_selector are the
+ kernel's CS. The value event\_address specifies the address for an
+ interrupt handler dispatch routine and failsafe\_address specifies a
+ handler for application faults.
+
+\section{ fpu\_taskswitch(void)}
+Notify hypervisor that fpu registers needed to be save on context switch.
+
+\section{ sched\_op(unsigned long op)}
+Request scheduling operation from hypervisor. The options are: {\it
+yield}, {\it block}, and {\it shutdown}. {\it yield} keeps the
+calling domain run-able but may cause a reschedule if other domains
+are run-able. {\it block} removes the calling domain from the run
+queue and the domains sleeps until an event is delivered to it. {\it
+shutdown} is used to end the domain's execution and allows to specify
+whether the domain should reboot, halt or suspend..
+
+\section{ dom0\_op(dom0\_op\_t *op)}
+Administrative domain operations for domain management. The options are:
+
+{\it DOM0\_CREATEDOMAIN}: create new domain, specifying the name and memory usage
+in kilobytes.
+
+{\it DOM0\_CREATEDOMAIN}: create domain
+
+{\it DOM0\_PAUSEDOMAIN}: mark domain as unschedulable
+
+{\it DOM0\_UNPAUSEDOMAIN}: mark domain as schedulable
+
+{\it DOM0\_DESTROYDOMAIN}: deallocate resources associated with the domain
+
+{\it DOM0\_GETMEMLIST}: get list of pages used by the domain
+
+{\it DOM0\_SCHEDCTL}:
+
+{\it DOM0\_ADJUSTDOM}: adjust scheduling priorities for domain
+
+{\it DOM0\_BUILDDOMAIN}: do final guest OS setup for domain
+
+{\it DOM0\_GETDOMAINFO}: get statistics about the domain
+
+{\it DOM0\_GETPAGEFRAMEINFO}:
+
+{\it DOM0\_IOPL}: set IO privilege level
+
+{\it DOM0\_MSR}:
+
+{\it DOM0\_DEBUG}: interactively call pervasive debugger
+
+{\it DOM0\_SETTIME}: set system time
+
+{\it DOM0\_READCONSOLE}: read console content from hypervisor buffer ring
+
+{\it DOM0\_PINCPUDOMAIN}: pin domain to a particular CPU
+
+{\it DOM0\_GETTBUFS}: get information about the size and location of
+ the trace buffers (only on trace-buffer enabled builds)
+
+{\it DOM0\_PHYSINFO}: get information about the host machine
+
+{\it DOM0\_PCIDEV\_ACCESS}: modify PCI device access permissions
+
+{\it DOM0\_SCHED\_ID}: get the ID of the current Xen scheduler
+
+{\it DOM0\_SHADOW\_CONTROL}:
+
+{\it DOM0\_SETDOMAINNAME}: set the name of a domain
+
+{\it DOM0\_SETDOMAININITIALMEM}: set initial memory allocation of a domain
+
+{\it DOM0\_SETDOMAINMAXMEM}: set maximum memory allocation of a domain
+
+{\it DOM0\_GETPAGEFRAMEINFO2}:
+
+{\it DOM0\_SETDOMAINVMASSIST}: set domain VM assist options
+
+
+\section{ set\_debugreg(int reg, unsigned long value)}
+set debug register reg to value
+
+\section{ get\_debugreg(int reg)}
+ get the debug register reg
+
+\section{ update\_descriptor(unsigned long ma, unsigned long word1, unsigned long word2)}
+
+\section{ set\_fast\_trap(int idx)}
+ install traps to allow guest OS to bypass hypervisor
+
+\section{ dom\_mem\_op(unsigned int op, unsigned long *extent\_list, unsigned long nr\_extents, unsigned int extent\_order)}
+Increase or decrease memory reservations for guest OS
+
+\section{ multicall(void *call\_list, int nr\_calls)}
+Execute a series of hypervisor calls
+
+\section{ update\_va\_mapping(unsigned long page\_nr, unsigned long val, unsigned long flags)}
+
+\section{ set\_timer\_op(uint64\_t timeout)}
+Request a timer event to be sent at the specified system time.
+
+\section{ event\_channel\_op(void *op)}
+Iinter-domain event-channel management.
+
+\section{ xen\_version(int cmd)}
+Request Xen version number.
+
+\section{ console\_io(int cmd, int count, char *str)}
+Interact with the console, operations are:
+
+{\it CONSOLEIO\_write}: Output count characters from buffer str.
+
+{\it CONSOLEIO\_read}: Input at most count characters into buffer str.
+
+\section{ physdev\_op(void *physdev\_op)}
+
+\section{ grant\_table\_op(unsigned int cmd, void *uop, unsigned int count)}
+
+\section{ vm\_assist(unsigned int cmd, unsigned int type)}
+
+\section{ update\_va\_mapping\_otherdomain(unsigned long page\_nr, unsigned long val, unsigned long flags, uint16\_t domid)}
+
+\end{document}
--- /dev/null
+\documentclass[11pt,twoside,final,openright]{xenstyle}
+\usepackage{a4,graphicx,setspace}
+\setstretch{1.15}
+
+\begin{document}
+
+% TITLE PAGE
+\pagestyle{empty}
+\begin{center}
+\vspace*{\fill}
+\includegraphics{figs/xenlogo.eps}
+\vfill
+\vfill
+\vfill
+\begin{tabular}{l}
+{\Huge \bf Users' manual} \\[4mm]
+{\huge Xen v2.0 for x86} \\[80mm]
+
+{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
+{\Large University of Cambridge, UK} \\[20mm]
+{\large Last updated on 12th October, 2004}
+\end{tabular}
+\vfill
+\end{center}
+\cleardoublepage
+
+% TABLE OF CONTENTS
+\pagestyle{plain}
+\pagenumbering{roman}
+{ \parskip 0pt plus 1pt
+ \tableofcontents }
+\cleardoublepage
+
+% PREPARE FOR MAIN TEXT
+\pagenumbering{arabic}
+\raggedbottom
+\widowpenalty=10000
+\clubpenalty=10000
+\parindent=0pt
+\renewcommand{\topfraction}{.8}
+\renewcommand{\bottomfraction}{.8}
+\renewcommand{\textfraction}{.2}
+\renewcommand{\floatpagefraction}{.8}
+\setstretch{1.15}
+
+\newcommand{\path}[1]{{\tt #1}}
+
+\part{Introduction and Tutorial}
+\chapter{Introduction}
+
+{\bf
+DISCLAIMER: This documentation is currently under active development
+and as such there may be mistakes and omissions --- watch out for
+these and please report any you find to the developer's mailing list.
+Contributions of material, suggestions and corrections are welcome.
+}
+
+Xen is a { \em paravirtualising } virtual machine monitor (VMM) or
+``Hypervisor'' for the x86 processor architecture. Xen can securely
+multiplex heterogeneous virtual machines on a single physical with
+near-native performance. The virtual machine technology facilitates
+enterprise-grade functionality, including:
+
+\begin{itemize}
+\item Virtual machines with close to native performance.
+\item Live migration of running virtual machines.
+\item Excellent hardware support (use unmodified Linux device drivers).
+\item Suspend to disk / resume from disk of running virtual machines.
+\item Transparent copy on write disks.
+\item Sandboxed, restartable device drivers.
+\item Pervasive debugging - debug whole OSes, from kernel to applications.
+\end{itemize}
+
+Xen support is available for increasingly many operating systems. The
+following OSs have either been ported already or a port is in
+progress:
+\begin{itemize}
+\item Linux 2.4
+\item Linux 2.6
+\item NetBSD 2.0
+\item Dragonfly BSD
+\item FreeBSD 5.3
+\item Plan 9
+% \item Windows XP
+\end{itemize}
+
+Right now, Linux 2.4, Linux 2.6 and NetBSD are available for Xen 2.0.
+It is intended that Xen support be integrated into the official
+releases of Linux 2.6, NetBSD 2.0, FreeBSD and Dragonfly BSD.
+
+Even running multiple copies of Linux can be very useful, providing a
+means of containing faults to one OS image, providing performance
+isolation between the various OS instances and trying out multiple
+distros.
+
+% The Windows XP port is only available to those who have signed the
+% Microsoft Academic Source License. Publically available XP support
+% will not be available for the foreseeable future (this may change when
+% Intel's Vanderpool Technology becomes available).
+
+Possible usage scenarios for Xen include:
+\begin{description}
+\item [Kernel development] test and debug kernel modifications in a
+ sandboxed virtual machine --- no need for a separate test
+ machine
+\item [Multiple OS Configurations] run multiple operating systems
+ simultaneously, for instance for compatibility or QA purposes
+\item [Server consolidation] move multiple servers onto one box,
+ provided performance and fault isolation at virtual machine
+ boundaries
+\item [Cluster computing] improve manageability and efficiency by
+ running services in virtual machines, isolated from
+ machine-specifics and load balance using live migration
+\item [High availability computing] run device drivers in sandboxed
+ domains for increased robustness
+\item [Hardware support for custom OSes] export drivers from a
+ mainstream OS (e.g. Linux) with good hardware support
+ to your custom OS, avoiding the need for you to port existing
+ drivers to achieve good hardware support
+\end{description}
+
+\section{Structure}
+
+\subsection{High level}
+
+A Xen system has multiple layers. The lowest layer is Xen itself ---
+the most privileged piece of code in the system. On top of Xen run
+guest operating system kernels. These are scheduled pre-emptively by
+Xen. On top of these run the applications of the guest OSs. Guest
+OSs are responsible for scheduling their own applications within the
+time allotted to them by Xen.
+
+One of the domains --- { \em Domain 0 } --- is privileged. It is
+started by Xen at system boot and is responsible for initialising and
+managing the whole machine. Domain 0 builds other domains and manages
+their virtual devices. It also performs suspend, resume and
+migration of other virtual machines. Where it is used, the X server
+is also run in domain 0.
+
+Within Domain 0, a process called ``Xend'' runs to manage the system.
+Xend is responsible for managing virtual machines and providing access
+to their consoles. Commands are issued to Xend over an HTTP
+interface, either from a command-line tool or from a web browser.
+
+XXX need diagram(s) here to make this make sense
+
+\subsection{Paravirtualisation}
+
+Paravirtualisation allows very high performance virtual machine
+technology, even on architectures (like x86) which are traditionally
+hard to virtualise.
+
+Paravirtualisation requires guest operating systems to be { \em ported
+} to run on the VMM. This process is similar to a port of an
+operating system to a new hardware platform. Although operating
+system kernels must explicitly support Xen in order to run in a
+virtual machine, { \em user space applications and libraries
+do not require modification }.
+
+\section{Hardware Support}
+
+Xen currently runs on the x86 architecture, but could in principle be
+ported to others. In fact, it would have been rather easier to write
+Xen for pretty much any other architecture as x86 is particularly
+tricky to handle. A good description of Xen's design, implementation
+and performance is contained in the October 2003 SOSP paper, available
+at:\\
+{\tt http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}\\
+Work to port Xen to x86\_64 and IA64 is currently underway.
+
+Xen requires a ``P6'' or newer processor (e.g. Pentium Pro, Celeron,
+Pentium II, Pentium III, Pentium IV, Xeon, AMD Athlon, AMD Duron).
+Multiprocessor machines are supported, and we also have basic support
+for HyperThreading (SMT), although this remains a topic for ongoing
+research. We're also working on an x86\_64 port (though Xen already
+runs on these systems just fine in 32-bit mode).
+
+Xen can currently use up to 4GB of memory. It is possible for x86
+machines to address up to 64GB of physical memory but (unless an
+external developer volunteers) there are no plans to support these
+systems. The x86\_64 port is the planned route to supporting more
+than 4GB of memory.
+
+Xen offloads most of the hardware support issues to the guest OS
+running in Domain 0. Xen itself only contains code to detect and
+start additional processors, setup interrupt routing and perform PCI
+bus enumeration. Device drivers run within a privileged guest OS
+rather than within Xen itself. This means that we should be
+compatible with the majority of device hardware supported by Linux.
+The default XenLinux build contains support for relatively modern
+server-class network and disk hardware, but you can add support for
+other hardware by configuring your XenLinux kernel in the normal way
+(e.g. \verb_# make ARCH=xen menuconfig_).
+
+\section{History}
+
+
+``Xen'' is a Virtual Machine Monitor (VMM) originally developed by the
+Systems Research Group of the University of Cambridge Computer
+Laboratory, as part of the UK-EPSRC funded XenoServers project.
+
+The XenoServers project aims to provide a ``public infrastructure for
+global distributed computing'', and Xen plays a key part in that,
+allowing us to efficiently partition a single machine to enable
+multiple independent clients to run their operating systems and
+applications in an environment providing protection, resource
+isolation and accounting. The project web page contains further
+information along with pointers to papers and technical reports:
+{\tt http://www.cl.cam.ac.uk/xeno}
+
+Xen has since grown into a project in its own right, enabling us to
+investigate interesting research issues regarding the best techniques
+for virtualizing resources such as the CPU, memory, disk and network.
+The project has been bolstered by support from Intel Research
+Cambridge, and HP Labs, who are now working closely with us.
+% We're also in receipt of support from Microsoft Research Cambridge to
+% port Windows XP to run on Xen.
+
+Xen was first described in the 2003 paper at SOSP \\
+({\tt http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}).
+The first public release of Xen (1.0) was made in October 2003. Xen
+was developed as a research project by the University of Cambridge
+Computer Laboratory (UK). Xen was the first Virtual Machine Monitor
+to make use of {\em paravirtualisation} to achieve near-native
+performance virtualisation of commodity operating systems. Since
+then, Xen has been extensively developed and is now used in production
+scenarios on multiple sites.
+
+Xen 2.0 is the latest release, featuring greatly enhanced hardware
+support, configuration flexibility, usability and a larger complement
+of supported operating systems. We think that Xen has the potential
+to become {\em the} definitive open source virtualisation solution and
+will work to conclusively achieve that position.
+
+
+\chapter{Installation}
+
+The Xen distribution includes three main components: Xen itself,
+utilities to convert a standard Linux tree to run on Xen and the
+userspace tools required to operate a Xen-based system.
+
+This manual describes how to install the Xen 2.0 distribution from
+source. Alternatively, there may be packages available for your
+operating system distribution.
+
+\section{Prerequisites}
+\label{sec:prerequisites}
+\begin{itemize}
+\item A working installation of your favourite Linux distribution.
+\item A working installation of the GRUB bootloader.
+\item An installation of Twisted v1.3 or above (see {\tt
+http://www.twistedmatrix.com}). There may be a package available for
+your distribution; alternatively it can be installed by running {\tt \#
+make install-twisted} in the root of the Xen source tree.
+\item The Linux bridge control tools (see {\tt
+http://bridge.sourceforge.net}). There may be packages of these tools
+available for your distribution.
+\item Linux IP Routing Tools
+\item make
+\item gcc
+\item libcurl
+\item zlib-dev
+\item python-dev
+\item python2.3-pycurl
+\item python2.3-twisted
+\end{itemize}
+
+\section{Optional}
+\begin{itemize}
+\item The Python logging package (see {\tt http://www.red-dove.com/})
+for additional Xend logging functionality.
+\end{itemize}
+
+\section{Install Bitkeeper (Optional)}
+
+To fetch a local copy, first download the BitKeeper tools.
+Download instructions must be obtained by filling out the provided
+form at: \\ {\tt
+http://www.bitmover.com/cgi-bin/download.cgi }
+
+The BitKeeper install program is designed to be run with X. If X is
+not available, you can specify the install directory on the command
+line.
+
+\section{Download the Xen source code}
+
+\subsection{Using Bitkeeper}
+
+The public master BK repository for the 2.0 release lives at: \\
+{\tt bk://xen.bkbits.net/xen-2.0.bk}. You can use Bitkeeper to
+download it and keep it updated with the latest features and fixes.
+
+Change to the directory in which you want to put the source code, then
+run:
+\begin{verbatim}
+# bk clone bk://xen.bkbits.net/xen-2.0.bk
+\end{verbatim}
+
+Under your current directory, a new directory named `xen-2.0.bk' has
+been created, which contains all the source code for the Xen
+hypervisor and the Xen tools. The directory also contains `sparse' OS
+source trees, containing only the files that require changes to allow
+the OS to run on Xen.
+
+Once you have cloned the repository, you can update to the newest
+changes to the repository by running:
+\begin{verbatim}
+# cd xen-2.0.bk # to change into the local repository
+# bk pull # to update the repository
+\end{verbatim}
+
+\subsection{Without Bitkeeper}
+
+The Xen source tree is also available in gzipped tarball form from the
+Xen downloads page:\\
+{\tt http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html}.
+Prebuilt tarballs are also available from this page but are very large.
+
+\section{The distribution}
+
+The Xen source code repository is structured as follows:
+
+\begin{description}
+\item[\path{tools/}] Xen node controller daemon (Xend), command line tools,
+ control libraries
+\item[\path{xen/}] The Xen hypervisor itself.
+\item[\path{linux-2.4.27-xen/}] Xen support for Linux 2.4
+\item[\path{linux-2.6.8.1-xen/}] Xen support for Linux 2.6
+\item[\path{netbsd-2.0-xen-sparse/}] Xen support for NetBSD 2.0
+\item[\path{docs/}] various documentation files for users and developers
+\item[\path{extras/}] currently this contains the Mini OS, aimed at developers
+\end{description}
+
+\section{Build and install}
+
+The Xen makefile includes a target ``world'' that will do the
+following:
+
+\begin{itemize}
+\item Build Xen
+\item Build the control tools, including Xend
+\item Download (if necessary) and unpack the Linux 2.6 source code,
+ and patch it for use with Xen
+\item Build a Linux kernel to use in domain 0 and a smaller
+ unprivileged kernel, which can optionally be used for
+ unprivileged virtual machines.
+\end{itemize}
+
+Inspect the Makefile if you want to see what goes on during a build.
+Building Xen and the tools is straightforward, but XenLinux is more
+complicated. The makefile needs a `pristine' linux kernel tree which
+it will then add the Xen architecture files to. You can tell the
+makefile the location of the appropriate linux compressed tar file by
+setting the LINUX\_SRC environment variable, e.g. \\
+\verb!# LINUX_SRC=/tmp/linux-2.6.8.1.tar.bz2 make world! \\ or by
+placing the tar file somewhere in the search path of {\tt
+LINUX\_SRC\_PATH} which defaults to ``{\tt .:..}". If the makefile
+can't find a suitable kernel tar file it attempts to download it from
+kernel.org (this won't work if you're behind a firewall).
+
+After untaring the pristine kernel tree, the makefile uses the {\tt
+mkbuildtree} script to add the Xen patches to the kernel. It then
+builds two different XenLinux images, one with a ``-xen0'' extension
+which contains hardware device drivers and drivers for Xen's virtual
+devices, and one with a ``-xenU'' extension that just contains the
+virtual ones.
+
+The procedure is similar to build the Linux 2.4 port: \\
+\verb!# LINUX_SRC=/path/to/linux2.4/source make linux24!
+
+The NetBSD port can be built using: \\ \verb!# make netbsd! \\ The
+NetBSD port is built using a snapshot of the netbsd-2-0 cvs branch.
+The snapshot is downloaded as part of the build process, if it is not
+yet present in the {\tt NETBSD\_SRC\_PATH} search path. The build
+process also downloads a toolchain which includes all the tools
+necessary to build the NetBSD kernel under Linux.
+
+If you have an SMP machine you may wish to give the {\tt '-j4'}
+argument to make to get a parallel build.
+
+XXX Insert details on customising the kernel to be built.
+i.e. merging config files
+
+If you have an existing Linux kernel configuration that you would like
+to use for domain 0, you should copy it to
+install/boot/config-2.6.8.1-xen0. During the first build, you may be
+asked about some Xen-specific options. We advised accepting the
+defaults for these options.
+
+\framebox{\parbox{5in}{
+{\bf Distro specific:} \\
+{\it Gentoo} --- if not using udev (most installations, currently), you'll need
+to enable devfs and devfs mount at boot time in the xen0 config.
+}}
+
+The files produced by the build process are stored under the
+\path{install/} directory. To install them in their default
+locations, do: \\
+\verb_# make install_
+
+Alternatively, users with special installation requirements may wish
+to install them manually by copying the files to their appropriate
+destinations.
+
+Files in \path{install/boot/} include:
+\begin{itemize}
+\item \path{install/boot/xen.gz} The Xen 'kernel'
+\item \path{install/boot/vmlinuz-2.6.8.1-xen0} Domain 0 XenLinux kernel
+\item \path{install/boot/vmlinuz-2.6.8.1-xenU} Unprivileged XenLinux kernel
+\end{itemize}
+
+The difference between the two Linux kernels that are built is due to
+the configuration file used for each. The "U" suffixed unprivileged
+version doesn't contain any of the physical hardware device drivers
+--- it is 30\% smaller and hence may be preferred for your
+non-privileged domains. The ``0'' suffixed privileged version can be
+used to boot the system, as well as in driver domains and unprivileged
+domains.
+
+The \path{install/boot} directory will also contain the config files
+used for building the XenLinux kernels, and also versions of Xen and
+XenLinux kernels that contain debug symbols (\path{xen-syms} and
+\path{vmlinux-syms-2.6.8.1-xen0}) which are essential for interpreting crash
+dumps. Retain these files as the developers may wish to see them if
+you post on the mailing list.
+
+\section{Configuration}
+
+\subsection{GRUB Configuration}
+
+An entry should be added to \path{grub.conf} (often found under
+\path{/boot/} or \path{/boot/grub/}) to allow Xen / XenLinux to boot.
+This file is sometimes called \path{menu.lst}, depending on your
+distribution. The entry should look something like the following:
+
+\begin{verbatim}
+title Xen 2.0 / XenLinux 2.6.8.1
+ kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1
+ module /boot/vmlinuz-2.6.8.1-xen0 root=/dev/sda4 ro console=tty0 console=ttyS0
+\end{verbatim}
+
+The first line of the configuration (kernel...) tells GRUB where to
+find Xen itself and what boot parameters should be passed to it (in
+this case, setting domain 0's memory allocation and the settings for
+the serial port).
+
+The second line of the configuration describes the location of the
+XenLinux kernel that Xen should start and the parameters that should
+be passed to it (these are standard Linux parameters, identifying the
+root device and specifying it be initially mounted read only and
+instructing that console output be sent both to the screen and to the
+serial port).
+
+As always when installing a new kernel, it is recommended that you do
+not remove the original contents of \path{menu.lst} --- you may want
+to boot up with your old Linux kernel in future, particularly if you
+have problems.
+
+\framebox{\parbox{5in}{
+{\bf Distro specific:} \\
+{\it SuSE} --- Omit the {\tt ro} option from the XenLinux kernel
+command line, since the partition won't be remounted rw during boot.
+}}
+
+\subsection{Serial Console}
+
+In order to configure serial console output, it is necessary to add a
+line into \path{/etc/inittab}. The XenLinux console driver is
+designed to make this procedure the same as configuring a normal
+serial console. Add the line:
+
+{\tt c:2345:respawn:/sbin/mingetty ttyS0}
+
+\subsection{TLS Libraries}
+
+Users of the XenLinux 2.6 kernel should disable Thread Local Storage
+(e.g. by doing a {\tt mv /lib/tls /lib/tls.disabled}) before
+attempting to run with a XenLinux kernel. You can always reenable it
+by restoring the directory to its original location (i.e. {\tt mv
+ /lib/tls.disabled /lib/tls}).
+
+The TLS implementation uses segmentation in a way that is not
+permissable under Xen. If TLS is not disabled, an emulation mode is
+used within Xen which reduces performance substantially and is not
+guaranteed to work perfectly.
+
+\section{Test the new install}
+
+It should now be possible to restart the system and use Xen. Reboot
+as usual but choose the new Xen option when the Grub screen appears.
+
+What follows should look much like a conventional Linux boot. The
+first portion of the output comes from Xen itself, supplying low level
+information about itself and the machine it is running on. The
+following portion of the output comes from XenLinux itself.
+
+You may see some errors during the XenLinux boot. These are not
+necessarily anything to worry about --- they may result from kernel
+configuration differences between your XenLinux kernel and the one you
+usually use.
+
+When the boot completes, you should be able to log into your system as
+usual. If you are unable to log in to your system running Xen, you
+should still be able to reboot with your normal Linux kernel.
+
+
+\chapter{Starting a domain}
+
+The first step in creating a new domain is to prepare a root
+filesystem for it to boot off. Typically, this might be stored in a
+normal partition, an LVM or other volume manager partition, a disk
+file or on an NFS server.
+
+A simple way to do this is simply to boot from your standard OS
+install CD and install the distribution into another partition on your
+hard drive.
+
+{\em N.b } you can boot with Xen and XenLinux without installing any
+special userspace tools but will need to have the prerequisites
+described in Section~\ref{sec:prerequisites} and the Xen control tools
+installed before you proceed.
+
+\section{From the web interface}
+
+Boot the Xen machine and start Xensv (see Chapter~\ref{cha:xensv} for
+more details) using the command: \\
+\verb_# xensv start_ \\
+This will also start Xend (see Chapter~\ref{cha:xend} for more information).
+
+The domain management interface will then be available at {\tt
+http://your\_machine:8080/}. This provides a user friendly wizard for
+starting domains and functions for managing running domains.
+
+\section{From the command line}
+
+Full details of the {\tt xm} tool are found in Chapter~\ref{cha:xm}.
+
+This example explains how to use the \path{xmdefconfig} file. If you
+require a more complex setup, you will want to write a custom
+configuration file --- details of the configuration file formats are
+included in Chapter~\ref{cha:config}.
+
+The \path{xmexample1} file is a simple template configuration file
+for describing a single VM.
+
+The \path{xmexample2} file is a template description that is intended
+to be reused for multiple virtual machines. Setting the value of the
+{\tt vmid} variable on the {\tt xm} command line
+fills in parts of this template.
+
+Both of them can be found in \path{/etc/xen/}
+\subsection{Editing \path{xmdefconfig}}
+
+At minimum, you should edit the following variables in \path{/etc/xen/xmdefconfig}:
+
+\begin{description}
+\item[kernel] Set this to the path of the kernel you compiled for use
+ with Xen. [e.g. {\tt kernel =
+ '/root/xen-2.0.bk/install/boot/vmlinuz-2.4.27-xenU'}]
+\item[memory] Set this to the size of the domain's memory in
+megabytes. [e.g. {\tt memory = 64 } ]
+\item[disk] Set the first entry in this list to calculate the offset
+of the domain's root partition, based on the domain ID. Set the
+second to the location of \path{/usr} (if you are sharing it between
+domains). [i.e. {\tt disk = ['phy:your\_hard\_drive\%d,sda1,w' \%
+(base\_partition\_number + vmid), 'phy:your\_usr\_partition,sda6,r' ]}
+\item[dhcp] Uncomment the dhcp variable, so that the domain will
+receive its IP address from a DHCP server. [i.e. {\tt dhcp=''dhcp''}]
+\end{description}
+
+You may also want to edit the {\bf vif} variable in order to choose
+the MAC address of the virtual ethernet interface yourself. For
+example: \\ \verb_vif = ['mac=00:06:AA:F6:BB:B3']_\\ If you do not set
+this variable, Xend will automatically generate a random MAC address
+from an unused range.
+
+If you don't have a \path{xmdefconfig} file, simply create your own
+by copying one of the \path{/etc/xen/xmexample} files.
+\subsection{Starting the domain}
+
+The {\tt xm} tool provides a variety of commands for managing domains.
+Use the {\tt create} command to start new domains. To start the
+virtual machine with virtual machine ID 1.
+
+\begin{verbatim}
+# xm create -c vmid=1
+\end{verbatim}
+
+The {\tt -c} switch causes {\tt xm} to turn into the domain's console
+after creation. The {\tt vmid=1} sets the {\tt vmid} variable used in
+the {\tt xmdefconfig} file. The tool uses the
+\path{/etc/xen/xmdefconfig} file, since no custom configuration file
+was specified on the command line.
+
+\section{Example: ttylinux}
+
+Ttylinux is a very small Linux distribution, designed to
+require very few resources. We will use it as a concrete example of
+how to start a Xen domain. Most users will probably want to install a
+more complex mainstream distribution once they have mastered the
+basics.
+
+\begin{enumerate}
+\item Download the ttylinux disk image from XXX where from?
+\item Create a configuration file like the following:
+\begin{verbatim}
+kernel = "/boot/vmlinuz-2.6.8.1-xenU" # or a 2.4 kernel or a xen0 kernel
+memory = 64
+name = "ttylinux"
+cpu = -1 # leave to Xen to pick
+nics = 1
+ip = "1.2.3.4"
+disk = ['file:/path/to/ttylinux-disk,sda1,w']
+root = "/dev/sda1 ro"
+\end{verbatim}
+\item Now start the domain and connect to its console:
+\begin{verbatim}
+xm create -f configfile -c
+\end{verbatim}
+\item Login as root, password root.
+\end{enumerate}
+
+\section{Starting / Stopping domains automatically}
+
+It is possible to have certain domains start automatically at boot
+time and to have dom0 wait for all running domains to shutdown before
+it shuts down the system.
+
+To specify a domain is to start at boot-time, place its
+configuration file (or a link to it) under \path{/etc/xen/auto/}.
+
+A Sys-V style init script for RedHat and LSB-compliant systems is
+provided and will be automatically copied to \path{/etc/init.d/}
+during install. You can then enable it in the appriate way for your
+distribution.
+
+For instance, on RedHat:
+
+\verb_# chkconfig --add xendomains_
+
+By default, this will start the boot-time domains in runlevels 3, 4
+and 5.
+
+You can also use the {\tt service} command to run this script manually, e.g:
+
+\verb_# service xendomains start_
+
+Starts all the domains with config files under /etc/xen/auto/.
+
+\verb_# service xendomains stop_
+
+Shuts down ALL running Xen domains.
+
+
+\chapter{Domain management tasks}
+
+The previous chapter described a simple example of how to configure
+and start a domain. This chapter summarises the tools available to
+manage running domains.
+
+\section{Command line management}
+
+Command line management tasks are also performed using the {\tt xm}
+tool. For online help for the commands available, type:\\
+\verb_# xm help_
+
+\subsection{Basic management commands}
+
+The most important {\tt xm} commands are: \\
+\verb_# xm list_ : Lists all domains running. \\
+\verb_# xm consoles_ : Gives information about the domain consoles. \\
+\verb_# xm console_: open a console to a domain.
+e.g. \verb_# xm console 1_ (open console to domain 1)
+
+\subsection{\tt xm list}
+
+The output of {\tt xm list} is in rows of the following format:\\
+\verb_name domid memory cpu state cputime console_
+
+\begin{description}
+\item[name] The descriptive name of the virtual machine.
+\item[domid] The number of the domain ID this virtual machine is running in.
+\item[memory] Memory size in megabytes.
+\item[cpu] The CPU this domain is running on.
+\item[state] Domain state consists of 5 fields:
+ \begin{description}
+ \item[r] running
+ \item[b] blocked
+ \item[p] paused
+ \item[s] shutdown
+ \item[c] crashed
+ \end{description}
+\item[cputime] How much CPU time (in seconds) the domain has used so far.
+\item[console] TCP port accepting connections to the domain's console.
+\end{description}
+
+The {\tt xm list} command also supports a long output format when the
+{\tt -l} switch is used. This outputs the fulls details of the
+running domains in Xend's SXP configuration format.
+
+For example, suppose the system is running the ttylinux domain as
+described earlier. The list command should produce output somewhat
+like the following:
+\begin{verbatim}
+# xm list
+Name Id Mem(MB) CPU State Time(s) Console
+Domain-0 0 251 0 r---- 172.2
+ttylinux 5 63 0 -b--- 3.0 9605
+\end{verbatim}
+
+Here we can see the details for the ttylinux domain, as well as for
+domain 0 (which of course is always running). Note that the console
+port for the ttylinux domain is 9605. This can be connected to by TCP
+using a terminal program (e.g. {\tt telnet} or, better, {\tt
+xencons}). The simplest way to connect is to use the {\tt xm console}
+command, specifying the domain name or ID. To connect to the console
+of the ttylinux domain, we could use:
+\begin{verbatim}
+# xm console ttylinux
+\end{verbatim}
+or:
+\begin{verbatim}
+# xm console 5
+\end{verbatim}
+
+\chapter{Other kinds of storage}
+
+It is possible to use any Linux block device to store virtual machine
+disk images. This chapter covers some of the possibilities; note that
+it is also possible to use network-based block devices and other
+unconventional block devices.
+
+\section{File-backed virtual block devices}
+
+It is possible to use a file in Domain 0 as the primary storage for a
+virtual machine. As well as being convenient, this also has the
+advantage that the virtual block device will be {\em sparse} --- space
+will only really be allocated as parts of the file are used. So if a
+virtual machine uses only half of its disk space then the file really
+takes up half of the size allocated.
+
+For example, to create a 2GB sparse file-backed virtual block device
+(actually only consumes 1KB of disk):
+
+\verb_# dd if=/dev/zero of=vm1disk bs=1k seek=2048k count=1_
+
+Make a file system in the disk file: \\
+\verb_# mkfs -t ext3 vm1disk_
+
+(when the tool asks for confirmation, answer `y')
+
+Populate the file system e.g. by copying from the current root:
+\begin{verbatim}
+# mount -o loop vm1disk /mnt
+# cp -ax / /mnt
+\end{verbatim}
+Tailor the file system by editing \path{/etc/fstab},
+\path{/etc/hostname}, etc (don't forget to edit the files in the
+mounted file system, instead of your domain 0 filesystem, e.g. you
+would edit \path{/mnt/etc/fstab} instead of \path{/etc/fstab} ). For
+this example put \path{/dev/sda1} to root in fstab.
+
+Now unmount (this is important!):\\
+\verb_# umount /mnt_
+
+In the configuration file set:\\
+\verb_disk = ['file:/full/path/to/vm1disk,sda1,w']_
+
+As the virtual machine writes to its `disk', the sparse file will be
+filled in and consume more space up to the original 2GB.
+
+\section{LVM-backed virtual block devices}
+
+XXX Put some simple examples here - would be nice if an LVM user could
+contribute some, although obviously users would have to read the LVM
+docs to do advanced stuff.
+
+\part{Quick Reference}
+
+\chapter{Domain Configuration Files}
+\label{cha:config}
+
+XXX Could use a little explanation about possible values
+
+Xen configuration files contain the following standard variables:
+
+\begin{description}
+\item[kernel] Path to the kernel image (on the server).
+\item[ramdisk] Path to a ramdisk image (optional).
+% \item[builder] The name of the domain build function (e.g. {\tt'linux'} or {\tt'netbsd'}.
+\item[memory] Memory size in megabytes.
+\item[cpu] CPU to assign this domain to.
+\item[nics] Number of virtual network interfaces.
+\item[vif] List of MAC addresses (random addresses are assigned if not given).
+\item[disk] Regions of disk to export to the domain.
+\item[dhcp] Set to {\tt 'dhcp'} if you want to DHCP allocate the IP address.
+\item[netmask] IP netmask.
+\item[gateway] IP address for the gateway (if any).
+\item[hostname] Set the hostname for the virtual machine.
+\item[root] Set the root device.
+\item[nfs\_server] IP address for the NFS server.
+\item[nfs\_root] Path of the root filesystem on the NFS server.
+\item[extra] Extra string to append to the kernel command line.
+\item[restart] Three possible options:
+ \begin{description}
+ \item[always] Always restart the domain, no matter what
+ its exit code is.
+ \item[never] Never restart the domain.
+ \item[onreboot] (restart the domain if it requests reboot).
+ \end{description}
+\end{description}
+
+It is also possible to include Python scripting commands in
+configuration files. This is done in the \path{xmdefconfig} file in
+order to handle the {\tt vmid} variable.
+
+
+\chapter{Xend (Node control daemon)}
+\label{cha:xend}
+
+The Xen Daemon (Xend) performs system management functions related to
+virtual machines. It forms a central point of control for a machine
+and can be controlled using an HTTP-based protocol. Xend must be
+running in order to start and manage virtual machines.
+
+Xend must be run as root because it needs access to privileged system
+management functions. A small set of commands may be issued on the
+Xend command line:
+
+\begin{tabular}{ll}
+\verb_# xend start_ & start Xend, if not already running \\
+\verb_# xend stop_ & stop Xend if already running \\
+\verb_# xend restart_ & restart Xend if running, otherwise start it \\
+\end{tabular}
+
+A SysV init script called {\tt xend} is provided to start Xend at boot
+time. {\tt make install} installs this script in {\path{/etc/init.d}.
+To enable it, you have to make symbolic links in the appropriate
+runlevel directories or use the {\tt chkconfig} tool, where available.
+
+Once Xend is running, more sophisticated administration can be done
+using the Xensv web interface (see Chapter~\ref{cha:xensv}).
+
+\chapter{Xensv (Web interface server)}
+\label{cha:xensv}
+
+Xensv is the server for the web control interface. It can be started
+using:\\
+\verb_# xensv start_ \\
+and stopped using:
+\verb_# xensv stop_ \\
+It will automatically start Xend if it is not already running.
+
+By default, Xensv will serve out the web interface on port 8080. This
+can be changed by editing {\tt
+/usr/lib/python2.3/site-packages/xen/sv/params.py}.
+
+Once Xensv is running, the web interface can be used to manage running
+domains and provides a user friendly domain creation wizard.
+
+\chapter{The xm tool}
+\label{cha:xm}
+
+XXX Add description of arguments and switches for all the options
+
+The xm tool is the primary tool for managing Xen from the console.
+The general format of an xm command line is:
+
+\begin{verbatim}
+# xm command [switches] [arguments] [variables]
+\end{verbatim}
+
+The available {\em switches } and {\em arguments} are dependent on the
+{\em command} chosen. The {\em variables} may be set using
+declarations of the form {\tt variable=value} and command line
+declarations override any of the values in the configuration file
+being used, including the standard variables described above and any
+custom variables (for instance, the \path{xmdefconfig} file uses a
+{\tt vmid} variable).
+
+The available commands are as follows:
+
+\begin{description}
+\item[balloon] Request a domain to adjust its memory footprint.
+\item[create] Create a new domain.
+\item[destroy] Kill a domain immediately.
+\item[list] List running domains.
+\item[shutdown] Ask a domain to shutdown.
+\item[dmesg] Fetch the Xen (not Linux!) boot output.
+\item[consoles] Lists the available consoles.
+\item[console] Connect to the console for a domain.
+\item[help] Get help on xm commands.
+\item[save] Suspend a domain to disk.
+\item[restore] Restore a domain from disk.
+\item[pause] Pause a domain's execution.
+\item[unpause] Unpause a domain.
+\item[pincpu] Pin a domain to a CPU.
+\item[bvt] Set BVT scheduler parameters for a domain.
+\item[bvt\_ctxallow] Set the BVT context switching allowance for the system.
+\item[atropos] Set the atropos parameters for a domain.
+\item[rrobin] Set the round robin time slice for the system.
+\item[info] Get information about the Xen host.
+\item[call] Call a Xend HTTP API function directly.
+\end{description}
+
+For a detailed overview of switches, arguments and variables to each command
+try
+\begin{verbatim}
+# xm help command
+\end{verbatim}
+
+\chapter{Glossary}
+
+\begin{description}
+\item[Atropos] One of the CPU schedulers provided by Xen.
+ Atropos provides domains with absolute shares
+ of the CPU, with timeliness guarantees and a
+ mechanism for sharing out ``slack time''.
+
+\item[BVT] The BVT scheduler is used to give proportional
+ fair shares of the CPU to domains.
+
+\item[Exokernel] A minimal piece of privileged code, similar to
+ a {\bf microkernel} but providing a more
+ `hardware-like' interface to the tasks it
+ manages. This is similar to a paravirtualising
+ VMM like {\bf Xen} but was designed as a new
+ operating system structure, rather than
+ specifically to run multiple conventional OSs.
+
+\item[Domain] A domain is the execution context that
+ contains a running { \bf virtual machine }.
+ The relationship between virtual machines
+ and domains on Xen is similar to that between
+ programs and processes in an operating
+ system: a virtual machine is a persistent
+ entity that resides on disk (somewhat like
+ a program). When it is loaded for execution,
+ it runs in a domain. Each domain has a
+ { \bf domain ID }.
+
+\item[Domain 0] The first domain to be started on a Xen
+ machine. Domain 0 is responsible for managing
+ the system.
+
+\item[Domain ID] A unique identifier for a { \bf domain },
+ analogous to a process ID in an operating
+ system. Apart from domain
+
+\item[Full virtualisation] An approach to virtualisation which
+ requires no modifications to the hosted
+ operating system, providing the illusion of
+ a complete system of real hardware devices.
+
+\item[Hypervisor] An alternative term for { \bf VMM }, used
+ because it means ``beyond supervisor'',
+ since it is responsible for managing multiple
+ ``supervisor'' kernels.
+
+\item[Live migration] A technique for moving a running virtual
+ machine to another physical host, without
+ stopping it or the services running on it.
+
+\item[Microkernel] A small base of code running at the highest
+ hardware privilege level. A microkernel is
+ responsible for sharing CPU and memory (and
+ sometimes other devices) between less
+ privileged tasks running on the system.
+ This is similar to a VMM, particularly a
+ {\bf paravirtualising} VMM but typically
+ addressing a different problem space and
+ providing different kind of interface.
+
+\item[NetBSD/Xen] A port of NetBSD to the Xen architecture.
+
+\item[Paravirtualisation] An approach to virtualisation which requires
+ modifications to the operating system in
+ order to run in a virtual machine. Xen
+ uses paravirtualisation but preserves
+ binary compatibility for user space
+ applications.
+
+\item[Shadow pagetables] A technique for hiding the layout of machine
+ memory from a virtual machine's operating
+ system. Used in some {\bf VMM}s to provide
+ the illusion of contiguous physical memory,
+ in Xen this is used during
+ {\bf live migration}.
+
+\item[Virtual Machine] The environment in which a hosted operating
+ system runs, providing the abstraction of a
+ dedicated machine. A virtual machine may
+ be identical to the underlying hardware (as
+ in { \bf full virtualisation }, or it may
+ differ, as in { \bf paravirtualisation }.
+
+\item[VMM] Virtual Machine Monitor - the software that
+ allows multiple virtual machines to be
+ multiplexed on a single physical machine.
+
+\item[Xen] Xen is a paravirtualising virtual machine
+ monitor, developed primarily by the
+ Systems Research Group at the University
+ of Cambridge Computer Laboratory.
+
+\item[XenLinux] Official name for the port of the Linux kernel
+ that runs on Xen.
+
+\end{description}
+
+\part{Advanced Topics}
+
+\chapter{Advanced Network Configuration}
+
+For simple systems with a single ethernet interface with a simple
+configuration, the default installation should work ``out of the
+box''. More complicated network setups, for instance with multiple
+ethernet interfaces and / or existing bridging setups will require
+some special configuration.
+
+The purpose of this chapter is to describe the mechanisms provided by
+xend to allow a flexible configuration for Xen's virtual networking.
+
+\section{Xen networking scripts}
+
+Xen's virtual networking is configured by 3 shell scripts. These are
+called automatically by Xend when certain events occur, with arguments
+to the scripts providing further contextual information. These
+scripts are found by default in \path{/etc/xen}. The names and
+locations of the scripts can be configured in \path{xend-config.sxp}.
+
+\subsection{\path{network}}
+
+This script is called once when Xend is started and once when Xend is
+stopped. Its job is to do any advance preparation required for the
+Xen virtual network when Xend starts and to do any corresponding
+cleanup when Xend exits.
+
+In the default configuration, this script creates the bridge
+``xen-br0'' and moves eth0 onto that bridge, modifying the routing
+accordingly.
+
+In configurations where the bridge already exists, this script could
+be replaced with a link to \path{/bin/true} (for instance).
+
+When Xend exits, this script is called with the {\tt stop} argument,
+which causes it to delete the Xen bridge and remove {\tt eth0} from
+it, restoring the normal IP and routing configuration.
+
+\subsection{\path{vif-bridge}}
+
+This script is called for every domain virtual interface. This should
+do things like configuring firewalling rules for that interface and
+adding it to the appropriate bridge.
+
+By default, this adds and removes VIFs on the default Xen bridge.
+This script can be customized to properly deal with more complicated
+bridging setups.
+
+\chapter{Advanced Scheduling Configuration}
+
+\section{Scheduler selection}
+
+Xen offers a boot time choice between multiple schedulers. To select
+a scheduler, pass the boot parameter { \tt sched=sched\_name } to Xen,
+substituting the appropriate scheduler name. Details of the schedulers
+and their parameters are included below; future versions of the tools
+will provide a higher-level interface to these tools.
+
+It is expected that system administrators configure their system to
+use the scheduler most appropriate to their needs. Currently, the BVT
+scheduler is the recommended choice, since the Atropos scheduler is
+not finished.
+
+\section{Borrowed Virtual Time}
+
+{\tt sched=bvt } (the default) \\
+
+BVT provides proportional fair shares of the CPU time. It has been
+observed to penalise domains that block frequently (e.g. IO intensive
+domains), but this can be compensated by using warping.
+
+\subsection{Global Parameters}
+
+\begin{description}
+\item[ctx\_allow]
+ the context switch allowance is similar to the "quantum"
+ in traditional schedulers. It is the minimum time that
+ a scheduled domain will be allowed to run before being
+ pre-empted. This prevents thrashing of the CPU.
+\end{description}
+
+\subsection{Per-domain parameters}
+
+\begin{description}
+\item[mcuadv]
+ the MCU (Minimum Charging Unit) advance determines the
+ proportional share of the CPU that a domain receives. It
+ is set inversely proportionally to a domain's sharing weight.
+\item[warp]
+ the amount of "virtual time" the domain is allowed to warp
+ backwards
+\item[warpl]
+ the warp limit is the maximum time a domain can run warped for
+\item[warpu]
+ the unwarp requirement is the minimum time a domain must
+ run unwarped for before it can warp again
+\end{description}
+
+\section{Atropos}
+
+{\tt sched=atropos } \\
+
+Atropos is a Soft Real Time scheduler. It provides guarantees about
+absolute shares of the CPU (with a method for optionally sharing out
+slack CPU time on a best-effort basis) and can provide timeliness
+guarantees for latency-sensitive domains.
+
+Every domain has an associated period and slice. The domain should
+receive 'slice' nanoseconds every 'period' nanoseconds. This allows
+the administrator to configure both the absolute share of the CPU a
+domain receives and the frequency with which it is scheduled. When
+domains unblock, their period is reduced to the value of the latency
+hint (the slice is scaled accordingly so that they still get the same
+proportion of the CPU). For each subsequent period, the slice and
+period times are doubled until they reach their original values.
+
+Note: don't overcommit the CPU when using Atropos (i.e. don't reserve
+more CPU than is available - the utilisation should be kept to
+slightly less than 100% in order to ensure predictable behaviour).
+
+\subsection{Per-domain parameters}
+
+\begin{description}
+\item[slice]
+ The length of time per period that a domain is guaranteed.
+\item[period]
+ The period over which a domain is guaranteed to receive
+ its slice of CPU time.
+\item[latency]
+ The latency hint is used to control how soon after
+ waking up a domain should be scheduled.
+\item[xtratime]
+ This is a true (1) / false (0) flag that specifies whether
+ a domain should be allowed a share of the system slack time.
+\end{description}
+
+\section{Round Robin}
+
+{\tt sched=rrobin } \\
+
+The Round Robin scheduler is included as a simple demonstration of
+Xen's internal scheduler API. It is not intended for production use
+--- the other schedulers included are all more general and should give
+higher throughput.
+
+\subsection{Global parameters}
+
+\begin{description}
+\item[rr\_slice]
+ The maximum time each domain runs before the next
+ scheduling decision is made.
+\end{description}
+
+\chapter{Privileged domains}
+
+There are two possible types of privileges: IO privileges and
+administration privileges.
+
+\section{Driver domains (IO Privileges)}
+
+IO privileges can be assigned to allow a domain to drive PCI devices
+itself. This is used to support driver domains.
+
+Setting backend privileges is currently only supported in SXP format
+config files (??? is this true - there's nothing in xmdefconfig,
+anyhow). To allow a domain to function as a backend for others,
+somewhere within the {\tt vm} element of its configuration file must
+be a {\tt backend} element of the form {\tt (backend ({\em type}))}
+where {\tt \em type} may be either {\tt netif} or {\tt blkif},
+according to the type of virtual device this domain will service.
+After this domain has been built, Xend will connect all new and
+existing {\em virtual} devices (of the appropriate type) to that
+backend.
+
+Note that:
+\begin{itemize}
+\item a block backend cannot import virtual block devices from other
+domains
+\item a network backend cannot import virtual network devices from
+other domains
+\end{itemize}
+
+Thus (particularly in the case of block backends, which cannot import
+a virtual block device as their root filesystem), you may need to boot
+a backend domain from a ramdisk or a network device.
+
+The privilege to drive PCI devices may also be specified on a
+per-device basis. Xen will assign the minimal set of hardware
+privileges to a domain that are required to control its devices. This
+can be configured in either format of configuration file:
+
+\begin{itemize}
+\item SXP Format:
+ Include {\tt device} elements
+ {\tt (device (pci (bus {\em x}) (dev {\em y}) (func {\em z}))) } \\
+ inside the top-level {\tt vm} element. Each one specifies the address
+ of a device this domain is allowed to drive ---
+ the numbers {\em x},{\em y} and {\em z} may be in either decimal or
+ hexadecimal format.
+\item Flat Format: Include a list of PCI device addresses of the
+ format: \\ {\tt pci = ['x,y,z', ...] } \\ where each element in the
+ list is a string specifying the components of the PCI device
+ address, separated by commas. The components ({\tt \em x}, {\tt \em
+ y} and {\tt \em z}) of the list may be formatted as either decimal
+ or hexadecimal.
+\end{itemize}
+
+\section{Administration Domains}
+
+Administration privileges allow a domain to use the ``dom0
+operations'' (so called because they are usually available only to
+domain 0). A privileged domain can build other domains, set scheduling
+parameters, etc.
+
+% Support for other administrative domains is not yet available...
+
+\chapter{Xen build options}
+
+For most users, the default build of Xen will be adequate. For some
+advanced uses, Xen provides a number of build-time options:
+
+At build time, these options should be set as environment variables or
+passed on make's command-line. For example:
+
+\begin{verbatim}
+export option=y; make
+option=y make
+make option1=y option2=y
+\end{verbatim}
+
+\section{List of options}
+
+{\bf verbose=y }\\
+Enable debugging messages when Xen detects an unexpected condition.
+Also enables console output from all domains. \\
+{\bf debug=y }\\
+Enable debug assertions. Implies {\bf verbose=y }.
+(Primarily useful for tracing bugs in Xen). \\
+{\bf debugger=y }\\
+Enable the in-Xen pervasive debugger (PDB).
+This can be used to debug Xen, guest OSes, and
+applications. For more information see the
+XenDebugger-HOWTO. \\
+{\bf perfc=y }\\
+Enable performance-counters for significant events
+within Xen. The counts can be reset or displayed
+on Xen's console via console control keys. \\
+{\bf trace=y }\\
+Enable per-cpu trace buffers which log a range of
+events within Xen for collection by control
+software. For more information see the chapter on debugging,
+in the Xen Interface Manual.
+
+\chapter{Boot options}
+
+\section{Xen boot options}
+
+These options are used to configure Xen's behaviour at runtime. They
+should be appended to Xen's command line, either manually or by
+editing \path{grub.conf}.
+
+{\bf ignorebiostables }\\
+ Disable parsing of BIOS-supplied tables. This may help with some
+ chipsets that aren't fully supported by Xen. If you specify this
+ option then ACPI tables are also ignored, and SMP support is
+ disabled. \\
+
+{\bf noreboot } \\
+ Don't reboot the machine automatically on errors. This is
+ useful to catch debug output if you aren't catching console messages
+ via the serial line. \\
+
+{\bf nosmp } \\
+ Disable SMP support.
+ This option is implied by 'ignorebiostables'. \\
+
+{\bf noacpi } \\
+ Disable ACPI tables, which confuse Xen on some chipsets.
+ This option is implied by 'ignorebiostables'. \\
+
+{\bf watchdog } \\
+ Enable NMI watchdog which can report certain failures. \\
+
+{\bf noht } \\
+ Disable Hyperthreading. \\
+
+{\bf badpage=$<$page number$>$[,$<$page number$>$] } \\
+ Specify a list of pages not to be allocated for use
+ because they contain bad bytes. For example, if your
+ memory tester says that byte 0x12345678 is bad, you would
+ place 'badpage=0x12345' on Xen's command line (i.e., the
+ last three digits of the byte address are not
+ included!). \\
+
+{\bf com1=$<$baud$>$,DPS[,$<$io\_base$>$,$<$irq$>$] \\
+ com2=$<$baud$>$,DPS[,$<$io\_base$>$,$<$irq$>$] } \\
+ Xen supports up to two 16550-compatible serial ports.
+ For example: 'com1=9600,8n1,0x408,5' maps COM1 to a
+ 9600-baud port, 8 data bits, no parity, 1 stop bit,
+ I/O port base 0x408, IRQ 5.
+ If the I/O base and IRQ are standard (com1:0x3f8,4;
+ com2:0x2f8,3) then they need not be specified. \\
+
+{\bf console=$<$specifier list$>$ } \\
+ Specify the destination for Xen console I/O.
+ This is a comma-separated list of, for example:
+\begin{description}
+ \item[vga] use VGA console and allow keyboard input
+ \item[com1] use serial port com1
+ \item[com2H] use serial port com2. Transmitted chars will
+ have the MSB set. Received chars must have
+ MSB set.
+ \item[com2L] use serial port com2. Transmitted chars will
+ have the MSB cleared. Received chars must
+ have MSB cleared.
+\end{description}
+ The latter two examples allow a single port to be
+ shared by two subsystems (e.g. console and
+ debugger). Sharing is controlled by MSB of each
+ transmitted/received character.
+ [NB. Default for this option is 'com1,tty'] \\
+
+{\bf conswitch=$<$switch-char$><$auto-switch-char$>$ } \\
+ Specify how to switch serial-console input between
+ Xen and DOM0. The required sequence is CTRL-<switch-char>
+ pressed three times. Specifying '`' disables switching.
+ The <auto-switch-char> specifies whether Xen should
+ auto-switch input to DOM0 when it boots -- if it is 'x'
+ then auto-switching is disabled. Any other value, or
+ omitting the character, enables auto-switching.
+ [NB. Default for this option is 'a'] \\
+
+{\bf nmi=xxx } \\
+ Specify what to do with an NMI parity or I/O error. \\
+ 'nmi=fatal': Xen prints a diagnostic and then hangs. \\
+ 'nmi=dom0': Inform DOM0 of the NMI. \\
+ 'nmi=ignore': Ignore the NMI. \\
+
+{\bf dom0\_mem=xxx } \\
+ Set the maximum amount of memory for domain0. \\
+
+{\bf tbuf\_size=xxx } \\
+ Set the size of the per-cpu trace buffers, in pages
+ (default 1). Note that the trace buffers are only
+ enabled in debug builds. Most users can ignore
+ this feature completely. \\
+
+{\bf sched=xxx } \\
+ Select the CPU scheduler Xen should use. The current
+ possibilities are 'bvt', 'atropos' and 'rrobin'. The
+ default is 'bvt'. For more information see
+ Sched-HOWTO.txt. \\
+
+{\bf pci\_dom0\_hide=(xx.xx.x)(yy.yy.y)... } \\
+Hide selected PCI devices from domain 0 (for instance, to stop it
+taking ownership of them so that they can be driven by another
+domain). Device IDs should be given in hex format. Bridge devices do
+not need to be hidden --- they are hidden implicitly, since guest OSes
+do not need to configure them.
+
+\section{XenLinux Options}
+
+{\bf xencons=xxx}
+Specify the device node to
+which the Xen virtual console driver is attached: \\
+ 'xencons=off': disable virtual console \\
+ 'xencons=tty': attach console to /dev/tty1 (tty0 at boot-time) \\
+ 'xencons=ttyS': attach console to /dev/ttyS0\\
+The default is ttyS for dom0 and tty for all other domains.
+
+\chapter{Further Support}
+
+If you have questions that are not answered by this manual, the
+sources of information listed below may be of interest to you. Note
+that bug reports, suggestions and contributions related to the
+software (or the documentation) should be sent to the Xen developers'
+mailing list (address below).
+
+\section{Other documentation}
+
+For developers interested in porting operating systems to Xen, the
+{\em Xen Interface Manual} is distributed in the \path{docs/}
+directory of the Xen source distribution. Various HOWTOs are
+available in \path{docs/HOWTOS} but this content is being integrated
+into this manual.
+
+\section{Online references}
+
+The official Xen web site is found at: \\
+{\tt
+http://www.cl.cam.ac.uk/Research/SRG/netos/xen/] }.
+
+Links to other
+documentation sources are listed at: \\ {\tt
+http://www.cl.cam.ac.uk/Research/SRG/netos/xen/documentation.html}.
+
+\section{Mailing lists}
+
+There are currently two official Xen mailing lists:
+
+\begin{description}
+\item[xen-devel@lists.sourceforge.net] Used for development
+discussions and requests for help. Subscribe at: \\
+{\tt http://lists.sourceforge.net/mailman/listinfo/xen-devel}
+\item[xen-announce@lists.sourceforge.net] Used for announcements only.
+Subscribe at: \\
+{\tt http://lists.sourceforge.net/mailman/listinfo/xen-announce}
+\item[xen-changelog@lists.sourceforge.net] Changelog feed
+from the unstable and 2.0 trees - developer oriented. Subscribe at: \\
+{\tt http://lists.sourceforge.net/mailman/listinfo/xen-changelog}
+\end{description}
+
+Although there is no specific user support list, the developers try to
+assist users who post on xen-devel. As the bulk of traffic on this
+list increases, a dedicated user support list may be introduced.
+
+\appendix
+
+\chapter{Installing Debian}
+
+The Debian project provides a tool called {\tt debootstrap} which
+allows a base Debian system to be installed into a filesystem without
+requiring the host system to have any Debian-specific software (such
+as {\tt apt}).
+
+Here's some info how to install Debian 3.1 (Sarge) for an unprivileged
+Xen domain:
+
+\begin{enumerate}
+\item Set up Xen 2.0 and test that it's working, as described earlier in
+ this manual.
+
+\item Create disk images for root-fs and swap (alternatively, you
+ might create dedicated partitions, LVM logical volumes, etc. if
+ that suits your setup).
+\begin{verbatim}
+dd if=/dev/zero of=/path/diskimage bs=1024k count=size_in_mbytes
+dd if=/dev/zero of=/path/swapimage bs=1024k count=size_in_mbytes
+\end{verbatim}
+ If you're going to use this filesystem / diskimage only as a
+ `template' for other vm diskimages, something like 300 MB should
+ be enough.. (of course it depends what kind of packages you are
+ planning to install to the template)
+
+\item Create the filesystem and initialise the swap image
+\begin{verbatim}
+mkfs.ext3 /path/diskimage
+mkswap /path/swapimage
+\end{verbatim}
+
+\item Mount the diskimage for installation
+\begin{verbatim}
+mount -o loop /path/diskimage /mnt/disk
+\end{verbatim}
+
+\item Install {\tt debootstrap}
+
+Make sure you have debootstrap installed on the host. If you are
+running Debian sarge (3.1 / testing) or unstable you can install it by
+running {\tt apt-get install debootstrap}. Otherwise, it can be
+downloaded from the Debian project website.
+
+\item Install debian base to the diskimage:
+\begin{verbatim}
+debootstrap --arch i386 sarge /mnt/disk \
+ http://ftp.<countrycode>.debian.org/debian
+\end{verbatim}
+
+You can use any other Debian http/ftp mirror you want.
+
+\item When debootstrap completes successfully, modify settings:
+\begin{verbatim}
+chroot /mnt/disk /bin/bash
+\end{verbatim}
+
+Edit the following files using vi or nano and make needed changes:
+\begin{verbatim}
+/etc/hostname
+/etc/hosts
+/etc/resolv.conf
+/etc/network/interfaces
+/etc/networks
+\end{verbatim}
+
+Set up access to the services, edit:
+\begin{verbatim}
+/etc/hosts.deny
+/etc/hosts.allow
+/etc/inetd.conf
+\end{verbatim}
+
+Add Debian mirror to:
+\begin{verbatim}
+/etc/apt/sources.list
+\end{verbatim}
+
+Create fstab like this:
+\begin{verbatim}
+/dev/sda1 / ext3 errors=remount-ro 0 1
+/dev/sda2 none swap sw 0 0
+proc /proc proc defaults 0 0
+\end{verbatim}
+
+Logout
+
+\item Umount the diskimage
+\begin{verbatim}
+umount /mnt/disk
+\end{verbatim}
+
+\item Create Xen 2.0 configuration file for the new domain. You can
+ use the example-configurations coming with xen as a template.
+
+ Make sure you have the following set up:
+\begin{verbatim}
+disk = [ 'file:/path/diskimage,sda1,w', 'file:/path/swapimage,sda2,w' ]
+root = "/dev/sda1 ro"
+\end{verbatim}
+
+\item Start the new domain
+\begin{verbatim}
+xm create -f domain_config_file
+\end{verbatim}
+
+Check that the new domain is running:
+\begin{verbatim}
+xm list
+\end{verbatim}
+
+\item Attach to the console of the new domain.
+ You should see something like this when starting the new domain:
+
+\begin{verbatim}
+Started domain testdomain2, console on port 9626
+\end{verbatim}
+
+ There you can see the ID of the console: 26. You can also list
+ the consoles with {\tt xm consoles"}. (ID is the last two
+ digits of the portnumber.)
+
+ Attach to the console:
+
+\begin{verbatim}
+xm console 26
+\end{verbatim}
+
+ or by telnetting to the port 9626 of localhost (the xm console
+ progam works better).
+
+\item Log in and run base-config
+
+ As a default there's no password for the root.
+
+ Check that everything looks OK, and the system started without
+ errors. Check that the swap is active, and the network settings are
+ correct.
+
+ Run {\tt /usr/sbin/base-config} to set up the Debian settings.
+
+ Set up the password for root using passwd.
+
+\item Done. You can exit the console by pressing {\tt Ctrl + ]}
+
+\end{enumerate}
+
+If you need to create new domains, you can just copy the contents of
+the `template'-image to the new disk images, either by mounting the
+template and the new image, and using {\tt cp -a} or {\tt tar} or by
+simply copying the image file. Once this is done, modify the
+image-specific settings (hostname, network settings, etc).
+
+\end{document}
+
+
+%% Other stuff without a home
+
+%% Instructions Re Python API
+
+%% Other Control Tasks using Python
+%% ================================
+
+%% A Python module 'Xc' is installed as part of the tools-install
+%% process. This can be imported, and an 'xc object' instantiated, to
+%% provide access to privileged command operations:
+
+%% # import Xc
+%% # xc = Xc.new()
+%% # dir(xc)
+%% # help(xc.domain_create)
+
+%% In this way you can see that the class 'xc' contains useful
+%% documentation for you to consult.
+
+%% A further package of useful routines (xenctl) is also installed:
+
+%% # import xenctl.utils
+%% # help(xenctl.utils)
+
+%% You can use these modules to write your own custom scripts or you can
+%% customise the scripts supplied in the Xen distribution.
--- /dev/null
+% -*- mode: LaTeX -*-
+\def\seca{\chapter}
+\def\secb{\section}
+\def\secc{\subsection}
+\def\secd{\subsubsection}
+\def\refa{chapter}
+\def\refb{section}
+\def\refc{section}
+\def\refd{section}
+
+%\def\seca{\section}
+%\def\secb{\subsection}
+%\def\secc{\subsubsection}
+%\def\refa{section}
+%\def\refb{section}
+%\def\refc{section}
+
+\documentclass[11pt,twoside,final,openright]{xenstyle}
+\usepackage{a4,graphicx,setspace}
+\setstretch{1.15}
+
+\begin{document}
+
+% TITLE PAGE
+\pagestyle{empty}
+\begin{center}
+\vspace*{\fill}
+\includegraphics{figs/xenlogo.eps}
+\vfill
+\vfill
+\vfill
+\begin{tabular}{l}
+{\Huge \bf Xend} \\[4mm]
+{\huge Xen v2.0 for x86} \\[80mm]
+
+{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
+{\Large University of Cambridge, UK} \\[20mm]
+{\large Last updated 30 August 2004}
+\end{tabular}
+\vfill
+\end{center}
+\cleardoublepage
+
+% TABLE OF CONTENTS
+\pagestyle{plain}
+\pagenumbering{roman}
+{ \parskip 0pt plus 1pt
+ \tableofcontents }
+\cleardoublepage
+% PREPARE FOR MAIN TEXT
+\pagenumbering{arabic}
+\raggedbottom
+\widowpenalty=10000
+\clubpenalty=10000
+\parindent=0pt
+\renewcommand{\topfraction}{.8}
+\renewcommand{\bottomfraction}{.8}
+\renewcommand{\textfraction}{.2}
+\renewcommand{\floatpagefraction}{.8}
+
+\setstretch{1.15}
+
+\seca{Introduction}
+Xend is the control daemon used to manage a machine running the Xen hypervisor.
+Xend is responsible for creating and destroying domains and managing their
+resources, such as virtual block devices and virtual network interfaces.
+
+Xend exists because the Xen hypervisor itself only manages the memory image
+of a domain and its scheduling. Xen provides the event channels that connect
+a domain to its devices, but is intentionally not involved in setting them up.
+
+Xend runs as a daemon in the privileged domain 0 and uses a low-level api
+to communicate with Xen via the domain 0 kernel. Xend exports its control
+interface to its clients using HTTP. Most programming languages have
+HTTP client libraries, so this interface can be used from most popular
+languages, for example Python, Perl, C, Java.
+Xend itself is written in Python, as are most of the Xen tools.
+
+The xend interface is intended to be a complete interface for the creation
+and management of domains. It supports domain creation, shutdown, reboot,
+destruction, save, restore and migration.
+
+When xend creates a domain it creates the domain memory image and communicates
+with the device driver domain(s) to configure the devices for the domain.
+This sets up connections between the domain and backend device controllers
+in the driver domain. When a domain shuts down its memory image cannot be fully released
+unless its backend devices are released and disconnected. This is done by xend.
+In order to protect against loss of this information when xend is restarted,
+xend maintains a persistent database of domain configurations. This allows
+xend to be stopped and restarted without loss of configuration information.
+For example, in order to upgrade the xend software.
+
+\seca{Domain lifecycle}
+\secb{Domain creation}
+Xend is instructed to create a domain by posting a domain\_create message to it,
+containing the domain configuration to be instantiated. The domain configuration
+is in sxp format and is as far as possible {\em fully-bound}, that is, all
+parameters are fully-specified. The domain configuration is saved in the filesystem
+so that it can be reused later if necessary.
+
+The domain configuration specifies the domain name, memory size, kernel image
+and parameters, and all the domain devices. Xend uses the Xen api to create
+the domain memory image, and then {\em builds} the memory image for the domain
+using the kernel image. At this point the domain exists, but it cannot be run because
+it has no devices. Xend then communicates with the device driver domain to create
+the configured devices. Once the devices are created it sets up event channels
+for them between the driver domain and the new domain, and notifies the new domain
+that its devices are connected. At this point the domain can be started.
+
+Xend is also responsible for managing domain consoles. When a domain is created,
+xend sets up a console event channel to the domain, and creates a TCP listening port
+for the domain console. When a connection is accepted to the port, xend
+connects input and output for the port to the domain console channel.
+
+\secb{Domain destruction}
+When a domain terminates, because it has been shutdown or it has crashed, the
+domain resources must be released so that the domain memory image can be
+finally removed from xen. Xend monitors the domains, and is also signaled by
+xen (using a VIRQ) when a domain exits. Xend examines the domain states and
+determines which domains have exited. It then communicates with the driver domain
+to release the devices for exited domains. Xend also closes any open console
+connections and removes the TCP listeners for exited domains.
+Once all devices have been released it instructs xen to destroy the memory image.
+
+\secb{Domain restart}
+Domain restart is the xen equivalent of a machine reboot. When a domain
+exits because it has been shutdown in reboot mode, its exit code is reboot.
+When examining domains to find those that have exited and destroy them,
+xend detects those that have exited for reboot and does not completely destroy
+them. It disconnects all their devices, and detaches the console listener
+from its channel to the domain, but does not close it. Instead it schedules
+a call to rebuild the domain from its configuration. This proceeds almost
+identically to creating the domain, except that the console listener is
+reused and connected to the new domain. This allows existing console
+connections to remain connected across a domain restart. The restarted
+domain keeps the same name and domain id.
+
+The determination of when to restart a domain is in fact slightly more
+complex than described above. A domain is configured with a
+{\em restart mode}. If the restart mode is {\em onreboot}, the default,
+restart happens when the domain is shutdown normally and
+exits with code reboot. If the restart mode is {\em never} the domain is
+not restarted. If the restart mode is {\em always} the domain is always
+restarted, regardless of how it exited.
+
+In order to prevent continual domain crash causing restart loops, xend
+has a {\em minimum restart time}. Xend remembers when a domain was last
+restarted and will fail a restart that happens inside the minimum
+restart time.
+
+\seca{Devices}
+\secb{Virtual network interfaces}
+Each virtual network interface (vif) has 2 parts: the font-end device in its domain,
+and the back-end device in the driver domain. Usually the driver domain is domain 0,
+and there is a linux network device corresponding to the vif. The linux device for
+interface N on domain D is called vifD.N. When a packet is sent on the vif in the
+domain the packet is received from the linux device. The linux devices are connected
+to network interfaces using ethernet bridging.
+
+The default setup is a bridge xen-br0, with eth0 connected to it, and the routes
+for eth0 directed at xen-br0. This is controlled by the xend network setup script,
+default {\tt /etc/xen/network}, which is run when xend starts.
+
+When the vifs for a domain are created, a vif control script, default {\tt /etc/xen/vif-bridge},
+is run to connect the vif to its bridge. The default script connects the vif
+to xen-br0 and optionally sets up iptables rules to prevent IP address spoofing.
+The bridge a vif is connected to can be defined in its configuration, and this is useful
+for setting up virtual networks using several bridges.
+
+\secb{Virtual block devices}
+Virtual block devices in a domain are interfaces onto back-end device drivers
+that export physical devices to domains. In the default configuration the back-end
+driver is in domain 0 and can export any linux block device to a domain. This includes
+physical disk partitions, LVM volumes and loopback mounts of files. In fact anything
+that linux can represent as a block device can be exported to a domain as virtual
+block device.
+
+\seca{Xend invocation}
+Xend is started (by root) using the command
+\begin{verbatim}
+xend start
+\end{verbatim}
+Xend can be stopped using
+\begin{verbatim}
+xend stop
+\end{verbatim}
+Xend must be started before any domains (apart from domain 0) can be created.
+If you try to use the {\tt xm} tool when xend is not running you will get a
+'connection refused' message.
+
+\secb{Xend configuration}
+Xend reads its own configuration from {\tt /etc/xen/xend-config.sxp}, which is
+a sequence of s-expressions. The configuration parameters are:
+\begin{itemize}
+
+\item xend-port: Port xend should use for the HTTP interface (default 8000).
+
+\item xend-address: Address xend should listen on.
+ Specifying 'localhost' prevents remote connections.
+ Specifying the empty string '' allows all connections, and is the default.
+
+\item network-script: The script used to start/stop networking for xend (default network).
+
+\item vif-bridge: The default bridge that virtual interfaces should be connected to
+ (default xen-br0).
+
+\item vif-script: The default script used to control virtual interfaces
+ (default vif-bridge).
+
+\item vif-antispoof: Whether iptables should be set up to prevent IP spoofing for
+ virtual interfaces (default yes).
+\end{itemize}
+
+Configuration scripts ({\it e.g.} for network-script) are looked for in {\tt /etc/xen}
+unless their name begins with '/'.
+
+Xend sends its log output to {\tt /var/log/xend.log}. This is a rotating logfile,
+and logs are moved onto {\tt xend.log.1} {\it etc.} as they get large. Old logs may
+be deleted.
+
+\secb{Xend database}
+Xend needs to make some data persistent, and it uses files under {\tt /var/xen/xend-db}
+for this. The persistent data is stored in files in SXP format. Domain information
+is saved when domains are created. When xend starts it reads the file {\tt /var/xen/lastboot}
+(if it exists) to determine the last time the system was rebooted. It compares this time
+with the last reboot time in {\tt wtmp} to determine if the system has been rebooted
+since xend last ran. If the system has been rebooted xend removes all its saved data
+that is not persistent across reboots (for example domain data).
+
+\seca{Xend HTTP Interface}
+ The xend interface uses HTTP 1.1 \cite{http} as its transport.
+Simple PUT and GET calls can encode parameters using the standard url-encoding
+for parameters: MIME type {\tt application/x-www-form-urlencoded}.
+When file upload is required, the {\tt multipart/form-data} encoding is used.
+See the HTML 4.1 specification for details \cite{html}.
+
+Xend functions as a webserver and supports two interfaces: one
+for web-browsers and one for programs.
+The web-browser interface returns replies in HTML and includes forms
+for interactive operations such as stopping domains and creating domains
+from an uploaded configuration. The programmatic interface usually returns replies
+in s-expression format. Both interfaces are accessed
+in exactly the same way over HTTP - the only difference is the data returned.
+
+The webserver distinguishes browsers from programs using the {\tt User-Agent}
+and {\tt Accept} headers in the HTTP request. If there is no {\tt User-Agent} or no
+{\tt Acccept} header, or {\tt Accept} includes the type {\tt application/sxp}, the
+webserver assumes the client is a program and returns SXP. Otherwise
+it assumes the client is a webserver and returns HTML.
+In some cases the return value is essentially a string, so {\tt Content-Type}
+{\tt text/plain} is returned.
+
+The HTTP api supported is listed below. All paths in it are relative to the
+server root, for example {\tt http://localhost:8000/xend}.
+As defined in the HTTP specification, we use GET for side-effect free
+operations that may safely be repeated, and POST for operations with
+side-effects. For each request we list the HTTP method (GET or POST),
+the url relative to the server root, the operation name and arguments (if any).
+The operation name is passed as request parameter 'op', and the arguments
+are passed by name. Operation name and parameters can be encoded using either
+encoding described above. We also list the corresponding api function from the
+Python client interface in {\tt xen.xend.XendClient}.
+
+\begin{itemize}
+\item {\tt GET /},\\
+ {\tt xend()}:\\
+ Get list of urls under xend root.
+
+\item {\tt GET /node},\\
+ {\tt xend\_node()}:\\
+ Get node information.
+
+\item {\tt POST /node shutdown()},\\
+ {\tt xend\_node\_shutdown()}:\\
+ Shutdown the node
+
+\item {\tt POST /node reboot()},\\
+ {\tt xend\_node\_reboot()}:\\
+ Reboot the node
+
+\item {\tt POST /node notify()}:\\
+ Set node notification url
+
+\item {\tt GET /node/dmesg},\\
+ {\tt xend\_node\_dmesg()}:\\
+ Get xen boot message.
+
+\item {\tt GET /node/log},\\
+ {\tt xend\_node\_log()}:\\
+ Get xend log.
+
+\item {\tt GET /domain}\\
+ {\tt xend\_domains()}:\\
+ Get list of domains.
+
+\item {\tt POST /domain create(config)},\\
+ {\tt xend\_domain\_create(config)}:\\
+ Create a domain.
+
+\item {\tt POST /domain restore(file)},\\
+ {\tt xend\_domain\_restore(filename)}:\\
+ Restore a saved domain.
+
+\item {\tt GET /domain/<dom>},\\
+ {\tt xend\_domain(dom)}:\\
+ Get domain information.
+
+\item {\tt POST /domain/[dom] configure(config)},\\
+ {\tt xend\_domain\_configure(dom, conf)}:\\
+ Configure an existing domain (for internal use by restore and migrate).
+
+\item {\tt POST /domain/[dom] unpause()},\\
+ {\tt xend\_domain\_unpause(dom)}:\\
+ Start domain running
+
+\item {\tt POST /domain/[dom] pause()},\\
+ {\tt xend\_domain\_pause(dom)}:\\
+ Stop domain running.
+
+\item {\tt POST /domain/[dom] shutdown(reason)},\\
+ {\tt xend\_domain\_shutdown(dom, reason)}:\\
+ Shutdown domain, reason can be reboot, poweroff, halt.
+
+\item {\tt POST /domain/[dom] destroy(reason)},\\
+ {\tt xend\_domain\_destroy(dom, reason)}:\\
+ Destroy domain, reason can be reboot, halt.
+
+\item {\tt POST /domain/[dom] save(file)},\\
+ {\tt xend\_domain\_save(dom, filename)}:\\
+ Save a domain to a file.
+
+\item {\tt POST /domain/[dom] migrate(dst)},\\
+ {\tt xend\_domain\_migrate(dom, dst)}:\\
+ Migrate a domain.
+
+\item {\tt POST /domain/[dom] pincpu(cpu)},\\
+ {\tt xend\_domain\_pincpu(self, id, cpu)}\\:
+ Pin a domain to a cpu.
+
+\item {\tt POST /domain/[dom] bvt\_set(mcuadv, warp, warpl, warpu)},\\
+ {\tt xend\_domain\_cpu\_bvt\_set(dom, mcuadv, warp, warpl, warpu)}:\\
+ Set BVT scheduler parameters.
+
+\item {\tt POST /domain/[dom] atropos\_set(period, slice, latency, xtratime)},\\
+ {\tt xend\_domain\_cpu\_atropos\_set(dom, period, slice, latency, xtratime)}:\\
+ Set atropos scheduler parameters.
+
+\item {\tt POST /domain/[dom] maxmem\_set(memory)},\\
+ {\tt xend\_domain\_maxmem\_set(dom, memory)}:\\
+ Set domain maximum memory limit.
+
+\item {\tt POST /domain/[dom] device\_create(config)}\\
+ {\tt xend\_domain\_device\_create(dom, config)}:\\
+ Add a device to a domain.
+
+\item {\tt POST /domain/[dom] device\_destroy(type, index)},\\
+ {\tt xend\_domain\_device\_destroy(dom, type, index)}:\\
+ Delete a device from a domain
+
+\item {\tt GET /domain/[dom] vifs()},\\
+ {\tt xend\_domain\_vifs(dom)}:\\
+ Get virtual network interfaces.
+
+\item {\tt GET /domain/[dom] vif(vif)},\\
+ {\tt xend\_domain\_vif(dom, vif)}:\\
+ Get virtual network interface.
+
+\item {\tt GET /domain/[dom] vbds()},\\
+ {\tt xend\_domain\_vbds(dom)}:\\
+ Get virtual block devices.
+
+\item {\tt GET /domain/[dom] vbd(vbd)},\\
+ {\tt xend\_domain\_vbd(dom, vbd)}:\\
+ Get virtual block device.
+
+\item {\tt GET /console},\\
+ {\tt xend\_consoles()}:\\
+ Get list of consoles.
+
+\item {\tt GET /console/[id]}\\
+ {\tt xend\_console(id)}:\\
+ Get information about a console.
+
+\item {\tt GET /console/[id] disconnect()}\\
+ {\tt xend\_console\_disconnect(self, id)}:\\
+ Disconnect any console TCP connection.
+
+\item {\tt GET /vnet}\\
+ {\tt xend\_vnets()}:\\
+ Get list of vnets (virtual networks).
+
+\item {\tt GET /vnet/[id]}\\
+ {\tt xend\_vnet(id)}:\\
+ Get information about a virtual network.
+
+\item {\tt POST /vnet create(config)}\\
+ {\tt xend\_vnet\_create(conf)}:\\
+ Create a vnet.
+
+\item {\tt POST /vnet/[id] delete()}\\
+ {\tt xend\_vnet\_delete(id)}:\\
+ Delete a vnet.
+
+\item {\tt POST /event inject(event)}\\
+ {\tt xend\_event\_inject(sxpr)}:\\
+ Inject an event.
+
+\end{itemize}
+
+\secb{Xend debugging interface}
+Xend also listens on port 8001. Connecting to this port (for example via telnet)
+allows access to some debugging functions:
+\begin{itemize}
+\item help: list functions
+\item traceon: turn xend tracing on
+\item traceoff: turn xend tracing off
+\item quit: disconnect.
+\item info: list console listeners, block and network device controllers.
+\end{itemize}
+
+When tracing is on xend logs all functions calls and exceptions to
+{\tt /var/log/xend.trace}.
+
+\begin{thebibliography}{99}
+
+\bibitem{html}
+HTML 4.01 Specification,\\
+http://www.w3.org/TR/html4/,\\
+W3C Recommendation, 24 December 1999.
+
+\bibitem{http}
+Hypertext Transfer Protocol -- HTTP/1.1,\\
+http://www.ietf.org/rfc/rfc2616.txt,\\
+RFC 2616, IETF 1999.
+
+\bibitem{ssh}
+http://www.openssh.org.
+
+\bibitem{stunnel}
+http://www.stunnel.org.
+
+\end{thebibliography}
+\end{document}
+++ /dev/null
-
-\usepackage{parskip,fancyheadings}
-
-\setcounter{secnumdepth}{10}
-\setcounter{tocdepth}{2}
-
-%\usepackage{sabon}
-\def\textos#1{#1}
-
-%
-% From PRB: Use FancyPlain style -- set up to produce draft
-% information and disable rules and section headings in headers and
-% footers.
-%
-
-% \filename
-
-\def\filename{thesis.tex}
-\let\savedinclude\include
-\def\include#1{\def\filename{#1.tex}\savedinclude{#1}}
-
-% \prtinttime
-
-\newcounter{hours}\newcounter{mins}
-\newcommand{\printtime}{%
- \setcounter{hours}{\time/60}%
- \setcounter{mins}{\time-\value{hours}*60}%
- \ifthenelse{\value{hours}<10}{0}{}\thehours:%
- \ifthenelse{\value{mins}<10}{0}{}\themins}
-
-
-% Final tweaks to the layout -- PRB/SMH/TLH
-
-\newcommand{\verylongpage}{\enlargethispage{2.5\baselineskip}}
-\newcommand{\longpage}{\enlargethispage{2\baselineskip}}
-\newcommand{\shortpage}{\enlargethispage{-2\baselineskip}}
-\newcommand{\quitelongpage}{\enlargethispage{1\baselineskip}}
-\newcommand{\quiteshortpage}{\enlargethispage{-1\baselineskip}}
-
-% Use instead of / to allow hyphenation -- PRB/SMH
-
-\def\slash{/\penalty 0\hskip 0pt\relax}
-
-%
-% Header/Footer
-%
-
-\pagestyle{fancyplain}
-\headrulewidth=0pt
-\footrulewidth=0pt
-\plainheadrulewidth=0pt
-\plainfootrulewidth=0pt
-
-\lhead[]{}
-\chead[]{}
-\rhead[]{}
-
-\lfoot[\sl\thepage]{}
-\cfoot[]{}
-\rfoot[]{\sl\thepage}
-
-%
-% Captions (from RF: make captions hang properly)
-%
-
-\makeatletter
-\long\def\@makecaption#1#2{%
- \vskip 10\p@
- \setbox\@tempboxa\hbox{\small #1: #2}%
- \ifdim \wd\@tempboxa >\hsize
- \@hangfrom{\small #1: }{\small #2}\par
- \else
- \hbox to\hsize{\hfil\box\@tempboxa\hfil}%
- \fi}
-\makeatother
-
-\makeatletter
-
-%
-% Keep mpars on the same side (we use them for hanging section
-% numbers).
-%
-
-\@mparswitchfalse
-\marginparsep=1ex
-
-%
-% Abandon ugly vertical justification
-%
-
-\raggedbottom
-
-%
-% Poor-mans small caps
-%
-
-%\font \psc = ptmr8t scaled 800
-%\renewcommand{\scdefault}{psc}
-
-\DeclareOldFontCommand{\sc}{\normalfont\scshape}{\@nomath\sc}
-
-%
-% Let footnotes fall right to the bottom of the page
-%
-
-\renewcommand\footnoterule{\vfill\hrule\vspace{6pt}}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%
-% Headings
-
-%
-% Fonts
-%
-
-% \font\sectionfont = phvr8t scaled 1400
-% \font\subsectionfont = phvr8t scaled 1200
-% \font\subsubsectionfont = phvr8t scaled 1000
-
-%
-% Chapter/Section names
-%
-
-\def\chaptermark#1{%
- \markboth {{\ifnum \c@secnumdepth >\m@ne
- \@chapapp\ \thechapter. \ \fi
- #1}}{}
- }
-
-\def\sectionmark#1{%
- \markright {{\ifnum \c@secnumdepth >\z@
- \thesection. \ \fi
- #1}}
- }
-
-%
-% Chapter heading components
-%
-
-\def\@chapter[#1]#2{\ifnum \c@secnumdepth >\m@ne
- \refstepcounter{chapter}%
- \typeout{\@chapapp\space\thechapter.}%
- \addcontentsline{toc}{chapter}%
- {\protect\numberline{\thechapter}#1}%
- \else
- \addcontentsline{toc}{chapter}{#1}
- \fi
- \chaptermark{#1}%
- \addtocontents{lof}{\protect\addvspace{10\p@}}%
- \addtocontents{lot}{\protect\addvspace{10\p@}}%
- \if@twocolumn
- \@topnewpage[\@makechapterhead{#2}]%
- \else
- \@makechapterhead{#2}%
- \@afterheading
- \fi
- }
-
-\def\@makechapterhead#1{%
- \vspace*{50\p@}%
- {\parindent \z@ \raggedright \reset@font
- \ifnum \c@secnumdepth >\m@ne
- \LARGE \@chapapp{} \thechapter
- \par
- \vskip 10\p@
- \fi
- \Huge #1\par
- \nobreak
- \vskip 20\p@
- }}
-
-\def\@schapter#1{\if@twocolumn
- \@topnewpage[\@makeschapterhead{#1}]%
- \else
- \@makeschapterhead{#1}%
- \@afterheading
- \fi}
-
-\def\@makeschapterhead#1{%
- \vspace*{50\p@}%
- {\parindent \z@ \raggedright
- \reset@font
- \Huge #1\par
- \nobreak
- \vskip 40\p@
- }}
-
-%
-% *Section heading components
-%
-
-\def\@startsection#1#2#3#4#5#6{%
- \if@noskipsec \leavevmode \fi
- \par
- \@tempskipa #4\relax
- \@afterindenttrue
- \ifdim \@tempskipa <\z@
- \@tempskipa -\@tempskipa \@afterindentfalse
- \fi
- \if@nobreak
- \everypar{}%
- \else
- \addpenalty\@secpenalty\addvspace\@tempskipa
- \fi
- \@ifstar
- {\@ssect{#3}{#4}{#5}{#6}}%
- {\@dblarg{\@sect{#1}{#2}{#3}{#4}{#5}{#6}}}}
-
-\def\@sect#1#2#3#4#5#6[#7]#8{%
- \ifnum #2>\c@secnumdepth
- \let\@svsec\@empty
- \else
- \refstepcounter{#1}%
- \protected@edef\@svsec{\@seccntformat{#1}\relax}%
- \fi
- \@tempskipa #5\relax
- \ifdim \@tempskipa>\z@
- \begingroup
- #6{\interlinepenalty \@M #8\@@par}%
- \reversemarginpar{\marginpar{{\rightline{\@svsec}}}}
- \endgroup
- \csname #1mark\endcsname{#7}%
- \addcontentsline{toc}{#1}{%
- \ifnum #2>\c@secnumdepth \else
- \protect\numberline{\csname the#1\endcsname}%
- \fi
- #7}%
- \else
- \def\@svsechd{%
- #6{\hskip #3\relax
- \@svsec #8}%
- \csname #1mark\endcsname{#7}%
- \addcontentsline{toc}{#1}{%
- \ifnum #2>\c@secnumdepth \else
- \protect\numberline{\csname the#1\endcsname}%
- \fi
- #7}}%
- \fi
- \@xsect{#5}
- }
-
-%
-% Table of contents
-%
-
-\renewcommand\contentsname{Table of contents}
-\renewcommand\tableofcontents{%
- \if@twocolumn
- \@restonecoltrue\onecolumn
- \else
- \@restonecolfalse
- \fi
- \chapter*{\contentsname
- \@mkboth{\contentsname}{}}%
- \@starttoc{toc}%
- \if@restonecol\twocolumn\fi
- }
-
-%
-% List of Figures
-%
-
-\renewcommand\listfigurename{List of figures}
-\renewcommand\listoffigures{%
- \if@twocolumn
- \@restonecoltrue\onecolumn
- \else
- \@restonecolfalse
- \fi
- \chapter*{\listfigurename
- \@mkboth{\listfigurename}{}}%
- \@starttoc{lof}%
- \if@restonecol\twocolumn\fi
- }
-
-%
-% List of Tables
-%
-
-\renewcommand\listtablename{List of tables}
-\renewcommand\listoftables{%
- \if@twocolumn
- \@restonecoltrue\onecolumn
- \else
- \@restonecolfalse
- \fi
- \chapter*{\listtablename
- \@mkboth{\listtablename}{}}%
- \@starttoc{lot}%
- \if@restonecol\twocolumn\fi
- }
-
-%
-% Glossary
-%
-
-\newcommand\gloname{Glossary}
-\newcommand\gloss{%
- \if@twocolumn
- \@restonecoltrue\onecolumn
- \else
- \@restonecolfalse
- \fi
- \chapter*{\gloname
- \@mkboth{\gloname}{}}%
- \input{glossary}
- \vfill
- \if@restonecol\twocolumn\fi
- }
-
-%
-% Bibliography
-%
-
-\renewenvironment{thebibliography}[1]
- {\chapter*{\bibname
- \@mkboth{\bibname}{}}%
- \list{\@biblabel{\arabic{enumiv}}}%
- {\settowidth\labelwidth{\@biblabel{#1}}%
- \leftmargin\labelwidth
- \advance\leftmargin\labelsep
-% \if@openbib
-% \advance\leftmargin\bibindent
-% \itemindent -\bibindent
-% \listparindent \itemindent
-% \parsep \z@
-% \fi
- \usecounter{enumiv}%
- \let\p@enumiv\@empty
- \renewcommand\theenumiv{\arabic{enumiv}}}%
-% \if@openbib
-% \renewcommand\newblock{\par}
-% \else
- \renewcommand\newblock{\hskip .11em \@plus.33em \@minus.07em}%
-% \fi
- \sloppy\clubpenalty4000\widowpenalty4000%
- \sfcode`\.=\@m}
- {\def\@noitemerr
- {\@latex@warning{Empty `thebibliography' environment}}%
- \endlist}
-
-%
-% Chapter
-%
-
-\renewcommand\chapter{%
- \if@openright\cleardoublepage\else\clearpage\fi
- \thispagestyle{plain}%
- \global\@topnum\z@
- \@afterindentfalse
- \secdef\@chapter\@schapter
- }
-
-%
-% *Sections
-%
-
-% \z@ -- zero?
-
-% \@startsection{name}{depth}
-% {indent}
-% {beforeskip \@plus foo \@minus bar}
-% foo: ... ; bar: jitter back up page?
-% {afterskip}
-% {style}
-
-\renewcommand\section{%
- \@startsection{section}{1}
- {\z@}%
- {-5ex \@plus 5ex \@minus -.5ex}%
- {2.5ex \@minus .5ex}%
- {\reset@font\Large}%
- }
-
-\renewcommand\subsection{%
- \@startsection{subsection}{2}
- {\z@}%
- {-3ex \@plus 3ex \@minus -.5ex}%
- {1.5ex \@minus .5ex}%
- {\reset@font\large}%
- }
-
-\renewcommand\subsubsection{%
- \@startsection{subsubsection}{3}
- {\z@}%
- {-1ex \@plus 1ex \@minus -.5ex}%
- {1ex \@minus .5ex}%
- {\reset@font\normalsize\sl}%
- }
-
-\makeatother
-\endinput
-
+++ /dev/null
-\documentclass[11pt,twoside,final,openright]{xenstyle}
-\usepackage{a4,graphicx,setspace}
-\setstretch{1.15}
-%\input{style.tex}
-
-\begin{document}
-
-% TITLE PAGE
-\pagestyle{empty}
-\begin{center}
-\vspace*{\fill}
-\includegraphics{eps/xenlogo.eps}
-\vfill
-\vfill
-\vfill
-\begin{tabular}{l}
-{\Huge \bf Users' manual} \\[4mm]
-{\huge Xen v2.0 for x86} \\[80mm]
-
-{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
-{\Large University of Cambridge, UK} \\[20mm]
-{\large Last updated on 12th October, 2004}
-\end{tabular}
-\vfill
-\end{center}
-\cleardoublepage
-
-% TABLE OF CONTENTS
-\pagestyle{plain}
-\pagenumbering{roman}
-{ \parskip 0pt plus 1pt
- \tableofcontents }
-\cleardoublepage
-
-% PREPARE FOR MAIN TEXT
-\pagenumbering{arabic}
-\raggedbottom
-\widowpenalty=10000
-\clubpenalty=10000
-\parindent=0pt
-\renewcommand{\topfraction}{.8}
-\renewcommand{\bottomfraction}{.8}
-\renewcommand{\textfraction}{.2}
-\renewcommand{\floatpagefraction}{.8}
-\setstretch{1.15}
-
-\newcommand{\path}[1]{{\tt #1}}
-
-\part{Introduction and Tutorial}
-\chapter{Introduction}
-
-{\bf
-DISCLAIMER: This documentation is currently under active development
-and as such there may be mistakes and omissions --- watch out for
-these and please report any you find to the developer's mailing list.
-Contributions of material, suggestions and corrections are welcome.
-}
-
-Xen is a { \em paravirtualising } virtual machine monitor (VMM) or
-``Hypervisor'' for the x86 processor architecture. Xen can securely
-multiplex heterogeneous virtual machines on a single physical with
-near-native performance. The virtual machine technology facilitates
-enterprise-grade functionality, including:
-
-\begin{itemize}
-\item Virtual machines with close to native performance.
-\item Live migration of running virtual machines.
-\item Excellent hardware support (use unmodified Linux device drivers).
-\item Suspend to disk / resume from disk of running virtual machines.
-\item Transparent copy on write disks.
-\item Sandboxed, restartable device drivers.
-\item Pervasive debugging - debug whole OSes, from kernel to applications.
-\end{itemize}
-
-Xen support is available for increasingly many operating systems. The
-following OSs have either been ported already or a port is in
-progress:
-\begin{itemize}
-\item Linux 2.4
-\item Linux 2.6
-\item NetBSD 2.0
-\item Dragonfly BSD
-\item FreeBSD 5.3
-\item Plan 9
-% \item Windows XP
-\end{itemize}
-
-Right now, Linux 2.4, Linux 2.6 and NetBSD are available for Xen 2.0.
-It is intended that Xen support be integrated into the official
-releases of Linux 2.6, NetBSD 2.0, FreeBSD and Dragonfly BSD.
-
-Even running multiple copies of Linux can be very useful, providing a
-means of containing faults to one OS image, providing performance
-isolation between the various OS instances and trying out multiple
-distros.
-
-% The Windows XP port is only available to those who have signed the
-% Microsoft Academic Source License. Publically available XP support
-% will not be available for the foreseeable future (this may change when
-% Intel's Vanderpool Technology becomes available).
-
-Possible usage scenarios for Xen include:
-\begin{description}
-\item [Kernel development] test and debug kernel modifications in a
- sandboxed virtual machine --- no need for a separate test
- machine
-\item [Multiple OS Configurations] run multiple operating systems
- simultaneously, for instance for compatibility or QA purposes
-\item [Server consolidation] move multiple servers onto one box,
- provided performance and fault isolation at virtual machine
- boundaries
-\item [Cluster computing] improve manageability and efficiency by
- running services in virtual machines, isolated from
- machine-specifics and load balance using live migration
-\item [High availability computing] run device drivers in sandboxed
- domains for increased robustness
-\item [Hardware support for custom OSes] export drivers from a
- mainstream OS (e.g. Linux) with good hardware support
- to your custom OS, avoiding the need for you to port existing
- drivers to achieve good hardware support
-\end{description}
-
-\section{Structure}
-
-\subsection{High level}
-
-A Xen system has multiple layers. The lowest layer is Xen itself ---
-the most privileged piece of code in the system. On top of Xen run
-guest operating system kernels. These are scheduled pre-emptively by
-Xen. On top of these run the applications of the guest OSs. Guest
-OSs are responsible for scheduling their own applications within the
-time allotted to them by Xen.
-
-One of the domains --- { \em Domain 0 } --- is privileged. It is
-started by Xen at system boot and is responsible for initialising and
-managing the whole machine. Domain 0 builds other domains and manages
-their virtual devices. It also performs suspend, resume and
-migration of other virtual machines. Where it is used, the X server
-is also run in domain 0.
-
-Within Domain 0, a process called ``Xend'' runs to manage the system.
-Xend is responsible for managing virtual machines and providing access
-to their consoles. Commands are issued to Xend over an HTTP
-interface, either from a command-line tool or from a web browser.
-
-XXX need diagram(s) here to make this make sense
-
-\subsection{Paravirtualisation}
-
-Paravirtualisation allows very high performance virtual machine
-technology, even on architectures (like x86) which are traditionally
-hard to virtualise.
-
-Paravirtualisation requires guest operating systems to be { \em ported
-} to run on the VMM. This process is similar to a port of an
-operating system to a new hardware platform. Although operating
-system kernels must explicitly support Xen in order to run in a
-virtual machine, { \em user space applications and libraries
-do not require modification }.
-
-\section{Hardware Support}
-
-Xen currently runs on the x86 architecture, but could in principle be
-ported to others. In fact, it would have been rather easier to write
-Xen for pretty much any other architecture as x86 is particularly
-tricky to handle. A good description of Xen's design, implementation
-and performance is contained in the October 2003 SOSP paper, available
-at:\\
-{\tt http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}\\
-Work to port Xen to x86\_64 and IA64 is currently underway.
-
-Xen requires a ``P6'' or newer processor (e.g. Pentium Pro, Celeron,
-Pentium II, Pentium III, Pentium IV, Xeon, AMD Athlon, AMD Duron).
-Multiprocessor machines are supported, and we also have basic support
-for HyperThreading (SMT), although this remains a topic for ongoing
-research. We're also working on an x86\_64 port (though Xen already
-runs on these systems just fine in 32-bit mode).
-
-Xen can currently use up to 4GB of memory. It is possible for x86
-machines to address up to 64GB of physical memory but (unless an
-external developer volunteers) there are no plans to support these
-systems. The x86\_64 port is the planned route to supporting more
-than 4GB of memory.
-
-Xen offloads most of the hardware support issues to the guest OS
-running in Domain 0. Xen itself only contains code to detect and
-start additional processors, setup interrupt routing and perform PCI
-bus enumeration. Device drivers run within a privileged guest OS
-rather than within Xen itself. This means that we should be
-compatible with the majority of device hardware supported by Linux.
-The default XenLinux build contains support for relatively modern
-server-class network and disk hardware, but you can add support for
-other hardware by configuring your XenLinux kernel in the normal way
-(e.g. \verb_# make ARCH=xen menuconfig_).
-
-\section{History}
-
-
-``Xen'' is a Virtual Machine Monitor (VMM) originally developed by the
-Systems Research Group of the University of Cambridge Computer
-Laboratory, as part of the UK-EPSRC funded XenoServers project.
-
-The XenoServers project aims to provide a ``public infrastructure for
-global distributed computing'', and Xen plays a key part in that,
-allowing us to efficiently partition a single machine to enable
-multiple independent clients to run their operating systems and
-applications in an environment providing protection, resource
-isolation and accounting. The project web page contains further
-information along with pointers to papers and technical reports:
-{\tt http://www.cl.cam.ac.uk/xeno}
-
-Xen has since grown into a project in its own right, enabling us to
-investigate interesting research issues regarding the best techniques
-for virtualizing resources such as the CPU, memory, disk and network.
-The project has been bolstered by support from Intel Research
-Cambridge, and HP Labs, who are now working closely with us.
-% We're also in receipt of support from Microsoft Research Cambridge to
-% port Windows XP to run on Xen.
-
-Xen was first described in the 2003 paper at SOSP \\
-({\tt http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}).
-The first public release of Xen (1.0) was made in October 2003. Xen
-was developed as a research project by the University of Cambridge
-Computer Laboratory (UK). Xen was the first Virtual Machine Monitor
-to make use of {\em paravirtualisation} to achieve near-native
-performance virtualisation of commodity operating systems. Since
-then, Xen has been extensively developed and is now used in production
-scenarios on multiple sites.
-
-Xen 2.0 is the latest release, featuring greatly enhanced hardware
-support, configuration flexibility, usability and a larger complement
-of supported operating systems. We think that Xen has the potential
-to become {\em the} definitive open source virtualisation solution and
-will work to conclusively achieve that position.
-
-
-\chapter{Installation}
-
-The Xen distribution includes three main components: Xen itself,
-utilities to convert a standard Linux tree to run on Xen and the
-userspace tools required to operate a Xen-based system.
-
-This manual describes how to install the Xen 2.0 distribution from
-source. Alternatively, there may be packages available for your
-operating system distribution.
-
-\section{Prerequisites}
-\label{sec:prerequisites}
-\begin{itemize}
-\item A working installation of your favourite Linux distribution.
-\item A working installation of the GRUB bootloader.
-\item An installation of Twisted v1.3 or above (see {\tt
-http://www.twistedmatrix.com}). There may be a package available for
-your distribution; alternatively it can be installed by running {\tt \#
-make install-twisted} in the root of the Xen source tree.
-\item The Linux bridge control tools (see {\tt
-http://bridge.sourceforge.net}). There may be packages of these tools
-available for your distribution.
-\item Linux IP Routing Tools
-\item make
-\item gcc
-\item libcurl
-\item zlib-dev
-\item python-dev
-\item python2.3-pycurl
-\item python2.3-twisted
-\end{itemize}
-
-\section{Optional}
-\begin{itemize}
-\item The Python logging package (see {\tt http://www.red-dove.com/})
-for additional Xend logging functionality.
-\end{itemize}
-
-\section{Install Bitkeeper (Optional)}
-
-To fetch a local copy, first download the BitKeeper tools.
-Download instructions must be obtained by filling out the provided
-form at: \\ {\tt
-http://www.bitmover.com/cgi-bin/download.cgi }
-
-The BitKeeper install program is designed to be run with X. If X is
-not available, you can specify the install directory on the command
-line.
-
-\section{Download the Xen source code}
-
-\subsection{Using Bitkeeper}
-
-The public master BK repository for the 2.0 release lives at: \\
-{\tt bk://xen.bkbits.net/xen-2.0.bk}. You can use Bitkeeper to
-download it and keep it updated with the latest features and fixes.
-
-Change to the directory in which you want to put the source code, then
-run:
-\begin{verbatim}
-# bk clone bk://xen.bkbits.net/xen-2.0.bk
-\end{verbatim}
-
-Under your current directory, a new directory named `xen-2.0.bk' has
-been created, which contains all the source code for the Xen
-hypervisor and the Xen tools. The directory also contains `sparse' OS
-source trees, containing only the files that require changes to allow
-the OS to run on Xen.
-
-Once you have cloned the repository, you can update to the newest
-changes to the repository by running:
-\begin{verbatim}
-# cd xen-2.0.bk # to change into the local repository
-# bk pull # to update the repository
-\end{verbatim}
-
-\subsection{Without Bitkeeper}
-
-The Xen source tree is also available in gzipped tarball form from the
-Xen downloads page:\\
-{\tt http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html}.
-Prebuilt tarballs are also available from this page but are very large.
-
-\section{The distribution}
-
-The Xen source code repository is structured as follows:
-
-\begin{description}
-\item[\path{tools/}] Xen node controller daemon (Xend), command line tools,
- control libraries
-\item[\path{xen/}] The Xen hypervisor itself.
-\item[\path{linux-2.4.27-xen/}] Xen support for Linux 2.4
-\item[\path{linux-2.6.8.1-xen/}] Xen support for Linux 2.6
-\item[\path{netbsd-2.0-xen-sparse/}] Xen support for NetBSD 2.0
-\item[\path{docs/}] various documentation files for users and developers
-\item[\path{extras/}] currently this contains the Mini OS, aimed at developers
-\end{description}
-
-\section{Build and install}
-
-The Xen makefile includes a target ``world'' that will do the
-following:
-
-\begin{itemize}
-\item Build Xen
-\item Build the control tools, including Xend
-\item Download (if necessary) and unpack the Linux 2.6 source code,
- and patch it for use with Xen
-\item Build a Linux kernel to use in domain 0 and a smaller
- unprivileged kernel, which can optionally be used for
- unprivileged virtual machines.
-\end{itemize}
-
-Inspect the Makefile if you want to see what goes on during a build.
-Building Xen and the tools is straightforward, but XenLinux is more
-complicated. The makefile needs a `pristine' linux kernel tree which
-it will then add the Xen architecture files to. You can tell the
-makefile the location of the appropriate linux compressed tar file by
-setting the LINUX\_SRC environment variable, e.g. \\
-\verb!# LINUX_SRC=/tmp/linux-2.6.8.1.tar.bz2 make world! \\ or by
-placing the tar file somewhere in the search path of {\tt
-LINUX\_SRC\_PATH} which defaults to ``{\tt .:..}". If the makefile
-can't find a suitable kernel tar file it attempts to download it from
-kernel.org (this won't work if you're behind a firewall).
-
-After untaring the pristine kernel tree, the makefile uses the {\tt
-mkbuildtree} script to add the Xen patches to the kernel. It then
-builds two different XenLinux images, one with a ``-xen0'' extension
-which contains hardware device drivers and drivers for Xen's virtual
-devices, and one with a ``-xenU'' extension that just contains the
-virtual ones.
-
-The procedure is similar to build the Linux 2.4 port: \\
-\verb!# LINUX_SRC=/path/to/linux2.4/source make linux24!
-
-The NetBSD port can be built using: \\ \verb!# make netbsd! \\ The
-NetBSD port is built using a snapshot of the netbsd-2-0 cvs branch.
-The snapshot is downloaded as part of the build process, if it is not
-yet present in the {\tt NETBSD\_SRC\_PATH} search path. The build
-process also downloads a toolchain which includes all the tools
-necessary to build the NetBSD kernel under Linux.
-
-If you have an SMP machine you may wish to give the {\tt '-j4'}
-argument to make to get a parallel build.
-
-XXX Insert details on customising the kernel to be built.
-i.e. merging config files
-
-If you have an existing Linux kernel configuration that you would like
-to use for domain 0, you should copy it to
-install/boot/config-2.6.8.1-xen0. During the first build, you may be
-asked about some Xen-specific options. We advised accepting the
-defaults for these options.
-
-\framebox{\parbox{5in}{
-{\bf Distro specific:} \\
-{\it Gentoo} --- if not using udev (most installations, currently), you'll need
-to enable devfs and devfs mount at boot time in the xen0 config.
-}}
-
-The files produced by the build process are stored under the
-\path{install/} directory. To install them in their default
-locations, do: \\
-\verb_# make install_
-
-Alternatively, users with special installation requirements may wish
-to install them manually by copying the files to their appropriate
-destinations.
-
-Files in \path{install/boot/} include:
-\begin{itemize}
-\item \path{install/boot/xen.gz} The Xen 'kernel'
-\item \path{install/boot/vmlinuz-2.6.8.1-xen0} Domain 0 XenLinux kernel
-\item \path{install/boot/vmlinuz-2.6.8.1-xenU} Unprivileged XenLinux kernel
-\end{itemize}
-
-The difference between the two Linux kernels that are built is due to
-the configuration file used for each. The "U" suffixed unprivileged
-version doesn't contain any of the physical hardware device drivers
---- it is 30\% smaller and hence may be preferred for your
-non-privileged domains. The ``0'' suffixed privileged version can be
-used to boot the system, as well as in driver domains and unprivileged
-domains.
-
-The \path{install/boot} directory will also contain the config files
-used for building the XenLinux kernels, and also versions of Xen and
-XenLinux kernels that contain debug symbols (\path{xen-syms} and
-\path{vmlinux-syms-2.6.8.1-xen0}) which are essential for interpreting crash
-dumps. Retain these files as the developers may wish to see them if
-you post on the mailing list.
-
-\section{Configuration}
-
-\subsection{GRUB Configuration}
-
-An entry should be added to \path{grub.conf} (often found under
-\path{/boot/} or \path{/boot/grub/}) to allow Xen / XenLinux to boot.
-This file is sometimes called \path{menu.lst}, depending on your
-distribution. The entry should look something like the following:
-
-\begin{verbatim}
-title Xen 2.0 / XenLinux 2.6.8.1
- kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1
- module /boot/vmlinuz-2.6.8.1-xen0 root=/dev/sda4 ro console=tty0 console=ttyS0
-\end{verbatim}
-
-The first line of the configuration (kernel...) tells GRUB where to
-find Xen itself and what boot parameters should be passed to it (in
-this case, setting domain 0's memory allocation and the settings for
-the serial port).
-
-The second line of the configuration describes the location of the
-XenLinux kernel that Xen should start and the parameters that should
-be passed to it (these are standard Linux parameters, identifying the
-root device and specifying it be initially mounted read only and
-instructing that console output be sent both to the screen and to the
-serial port).
-
-As always when installing a new kernel, it is recommended that you do
-not remove the original contents of \path{menu.lst} --- you may want
-to boot up with your old Linux kernel in future, particularly if you
-have problems.
-
-\framebox{\parbox{5in}{
-{\bf Distro specific:} \\
-{\it SuSE} --- Omit the {\tt ro} option from the XenLinux kernel
-command line, since the partition won't be remounted rw during boot.
-}}
-
-\subsection{Serial Console}
-
-In order to configure serial console output, it is necessary to add a
-line into \path{/etc/inittab}. The XenLinux console driver is
-designed to make this procedure the same as configuring a normal
-serial console. Add the line:
-
-{\tt c:2345:respawn:/sbin/mingetty ttyS0}
-
-\subsection{TLS Libraries}
-
-Users of the XenLinux 2.6 kernel should disable Thread Local Storage
-(e.g. by doing a {\tt mv /lib/tls /lib/tls.disabled}) before
-attempting to run with a XenLinux kernel. You can always reenable it
-by restoring the directory to its original location (i.e. {\tt mv
- /lib/tls.disabled /lib/tls}).
-
-The TLS implementation uses segmentation in a way that is not
-permissable under Xen. If TLS is not disabled, an emulation mode is
-used within Xen which reduces performance substantially and is not
-guaranteed to work perfectly.
-
-\section{Test the new install}
-
-It should now be possible to restart the system and use Xen. Reboot
-as usual but choose the new Xen option when the Grub screen appears.
-
-What follows should look much like a conventional Linux boot. The
-first portion of the output comes from Xen itself, supplying low level
-information about itself and the machine it is running on. The
-following portion of the output comes from XenLinux itself.
-
-You may see some errors during the XenLinux boot. These are not
-necessarily anything to worry about --- they may result from kernel
-configuration differences between your XenLinux kernel and the one you
-usually use.
-
-When the boot completes, you should be able to log into your system as
-usual. If you are unable to log in to your system running Xen, you
-should still be able to reboot with your normal Linux kernel.
-
-
-\chapter{Starting a domain}
-
-The first step in creating a new domain is to prepare a root
-filesystem for it to boot off. Typically, this might be stored in a
-normal partition, an LVM or other volume manager partition, a disk
-file or on an NFS server.
-
-A simple way to do this is simply to boot from your standard OS
-install CD and install the distribution into another partition on your
-hard drive.
-
-{\em N.b } you can boot with Xen and XenLinux without installing any
-special userspace tools but will need to have the prerequisites
-described in Section~\ref{sec:prerequisites} and the Xen control tools
-installed before you proceed.
-
-\section{From the web interface}
-
-Boot the Xen machine and start Xensv (see Chapter~\ref{cha:xensv} for
-more details) using the command: \\
-\verb_# xensv start_ \\
-This will also start Xend (see Chapter~\ref{cha:xend} for more information).
-
-The domain management interface will then be available at {\tt
-http://your\_machine:8080/}. This provides a user friendly wizard for
-starting domains and functions for managing running domains.
-
-\section{From the command line}
-
-Full details of the {\tt xm} tool are found in Chapter~\ref{cha:xm}.
-
-This example explains how to use the \path{xmdefconfig} file. If you
-require a more complex setup, you will want to write a custom
-configuration file --- details of the configuration file formats are
-included in Chapter~\ref{cha:config}.
-
-The \path{xmexample1} file is a simple template configuration file
-for describing a single VM.
-
-The \path{xmexample2} file is a template description that is intended
-to be reused for multiple virtual machines. Setting the value of the
-{\tt vmid} variable on the {\tt xm} command line
-fills in parts of this template.
-
-Both of them can be found in \path{/etc/xen/}
-\subsection{Editing \path{xmdefconfig}}
-
-At minimum, you should edit the following variables in \path{/etc/xen/xmdefconfig}:
-
-\begin{description}
-\item[kernel] Set this to the path of the kernel you compiled for use
- with Xen. [e.g. {\tt kernel =
- '/root/xen-2.0.bk/install/boot/vmlinuz-2.4.27-xenU'}]
-\item[memory] Set this to the size of the domain's memory in
-megabytes. [e.g. {\tt memory = 64 } ]
-\item[disk] Set the first entry in this list to calculate the offset
-of the domain's root partition, based on the domain ID. Set the
-second to the location of \path{/usr} (if you are sharing it between
-domains). [i.e. {\tt disk = ['phy:your\_hard\_drive\%d,sda1,w' \%
-(base\_partition\_number + vmid), 'phy:your\_usr\_partition,sda6,r' ]}
-\item[dhcp] Uncomment the dhcp variable, so that the domain will
-receive its IP address from a DHCP server. [i.e. {\tt dhcp=''dhcp''}]
-\end{description}
-
-You may also want to edit the {\bf vif} variable in order to choose
-the MAC address of the virtual ethernet interface yourself. For
-example: \\ \verb_vif = ['mac=00:06:AA:F6:BB:B3']_\\ If you do not set
-this variable, Xend will automatically generate a random MAC address
-from an unused range.
-
-If you don't have a \path{xmdefconfig} file, simply create your own
-by copying one of the \path{/etc/xen/xmexample} files.
-\subsection{Starting the domain}
-
-The {\tt xm} tool provides a variety of commands for managing domains.
-Use the {\tt create} command to start new domains. To start the
-virtual machine with virtual machine ID 1.
-
-\begin{verbatim}
-# xm create -c vmid=1
-\end{verbatim}
-
-The {\tt -c} switch causes {\tt xm} to turn into the domain's console
-after creation. The {\tt vmid=1} sets the {\tt vmid} variable used in
-the {\tt xmdefconfig} file. The tool uses the
-\path{/etc/xen/xmdefconfig} file, since no custom configuration file
-was specified on the command line.
-
-\section{Example: ttylinux}
-
-Ttylinux is a very small Linux distribution, designed to
-require very few resources. We will use it as a concrete example of
-how to start a Xen domain. Most users will probably want to install a
-more complex mainstream distribution once they have mastered the
-basics.
-
-\begin{enumerate}
-\item Download the ttylinux disk image from XXX where from?
-\item Create a configuration file like the following:
-\begin{verbatim}
-kernel = "/boot/vmlinuz-2.6.8.1-xenU" # or a 2.4 kernel or a xen0 kernel
-memory = 64
-name = "ttylinux"
-cpu = -1 # leave to Xen to pick
-nics = 1
-ip = "1.2.3.4"
-disk = ['file:/path/to/ttylinux-disk,sda1,w']
-root = "/dev/sda1 ro"
-\end{verbatim}
-\item Now start the domain and connect to its console:
-\begin{verbatim}
-xm create -f configfile -c
-\end{verbatim}
-\item Login as root, password root.
-\end{enumerate}
-
-\section{Starting / Stopping domains automatically}
-
-It is possible to have certain domains start automatically at boot
-time and to have dom0 wait for all running domains to shutdown before
-it shuts down the system.
-
-To specify a domain is to start at boot-time, place its
-configuration file (or a link to it) under \path{/etc/xen/auto/}.
-
-A Sys-V style init script for RedHat and LSB-compliant systems is
-provided and will be automatically copied to \path{/etc/init.d/}
-during install. You can then enable it in the appriate way for your
-distribution.
-
-For instance, on RedHat:
-
-\verb_# chkconfig --add xendomains_
-
-By default, this will start the boot-time domains in runlevels 3, 4
-and 5.
-
-You can also use the {\tt service} command to run this script manually, e.g:
-
-\verb_# service xendomains start_
-
-Starts all the domains with config files under /etc/xen/auto/.
-
-\verb_# service xendomains stop_
-
-Shuts down ALL running Xen domains.
-
-
-\chapter{Domain management tasks}
-
-The previous chapter described a simple example of how to configure
-and start a domain. This chapter summarises the tools available to
-manage running domains.
-
-\section{Command line management}
-
-Command line management tasks are also performed using the {\tt xm}
-tool. For online help for the commands available, type:\\
-\verb_# xm help_
-
-\subsection{Basic management commands}
-
-The most important {\tt xm} commands are: \\
-\verb_# xm list_ : Lists all domains running. \\
-\verb_# xm consoles_ : Gives information about the domain consoles. \\
-\verb_# xm console_: open a console to a domain.
-e.g. \verb_# xm console 1_ (open console to domain 1)
-
-\subsection{\tt xm list}
-
-The output of {\tt xm list} is in rows of the following format:\\
-\verb_name domid memory cpu state cputime console_
-
-\begin{description}
-\item[name] The descriptive name of the virtual machine.
-\item[domid] The number of the domain ID this virtual machine is running in.
-\item[memory] Memory size in megabytes.
-\item[cpu] The CPU this domain is running on.
-\item[state] Domain state consists of 5 fields:
- \begin{description}
- \item[r] running
- \item[b] blocked
- \item[p] paused
- \item[s] shutdown
- \item[c] crashed
- \end{description}
-\item[cputime] How much CPU time (in seconds) the domain has used so far.
-\item[console] TCP port accepting connections to the domain's console.
-\end{description}
-
-The {\tt xm list} command also supports a long output format when the
-{\tt -l} switch is used. This outputs the fulls details of the
-running domains in Xend's SXP configuration format.
-
-For example, suppose the system is running the ttylinux domain as
-described earlier. The list command should produce output somewhat
-like the following:
-\begin{verbatim}
-# xm list
-Name Id Mem(MB) CPU State Time(s) Console
-Domain-0 0 251 0 r---- 172.2
-ttylinux 5 63 0 -b--- 3.0 9605
-\end{verbatim}
-
-Here we can see the details for the ttylinux domain, as well as for
-domain 0 (which of course is always running). Note that the console
-port for the ttylinux domain is 9605. This can be connected to by TCP
-using a terminal program (e.g. {\tt telnet} or, better, {\tt
-xencons}). The simplest way to connect is to use the {\tt xm console}
-command, specifying the domain name or ID. To connect to the console
-of the ttylinux domain, we could use:
-\begin{verbatim}
-# xm console ttylinux
-\end{verbatim}
-or:
-\begin{verbatim}
-# xm console 5
-\end{verbatim}
-
-\chapter{Other kinds of storage}
-
-It is possible to use any Linux block device to store virtual machine
-disk images. This chapter covers some of the possibilities; note that
-it is also possible to use network-based block devices and other
-unconventional block devices.
-
-\section{File-backed virtual block devices}
-
-It is possible to use a file in Domain 0 as the primary storage for a
-virtual machine. As well as being convenient, this also has the
-advantage that the virtual block device will be {\em sparse} --- space
-will only really be allocated as parts of the file are used. So if a
-virtual machine uses only half of its disk space then the file really
-takes up half of the size allocated.
-
-For example, to create a 2GB sparse file-backed virtual block device
-(actually only consumes 1KB of disk):
-
-\verb_# dd if=/dev/zero of=vm1disk bs=1k seek=2048k count=1_
-
-Make a file system in the disk file: \\
-\verb_# mkfs -t ext3 vm1disk_
-
-(when the tool asks for confirmation, answer `y')
-
-Populate the file system e.g. by copying from the current root:
-\begin{verbatim}
-# mount -o loop vm1disk /mnt
-# cp -ax / /mnt
-\end{verbatim}
-Tailor the file system by editing \path{/etc/fstab},
-\path{/etc/hostname}, etc (don't forget to edit the files in the
-mounted file system, instead of your domain 0 filesystem, e.g. you
-would edit \path{/mnt/etc/fstab} instead of \path{/etc/fstab} ). For
-this example put \path{/dev/sda1} to root in fstab.
-
-Now unmount (this is important!):\\
-\verb_# umount /mnt_
-
-In the configuration file set:\\
-\verb_disk = ['file:/full/path/to/vm1disk,sda1,w']_
-
-As the virtual machine writes to its `disk', the sparse file will be
-filled in and consume more space up to the original 2GB.
-
-\section{LVM-backed virtual block devices}
-
-XXX Put some simple examples here - would be nice if an LVM user could
-contribute some, although obviously users would have to read the LVM
-docs to do advanced stuff.
-
-\part{Quick Reference}
-
-\chapter{Domain Configuration Files}
-\label{cha:config}
-
-XXX Could use a little explanation about possible values
-
-Xen configuration files contain the following standard variables:
-
-\begin{description}
-\item[kernel] Path to the kernel image (on the server).
-\item[ramdisk] Path to a ramdisk image (optional).
-% \item[builder] The name of the domain build function (e.g. {\tt'linux'} or {\tt'netbsd'}.
-\item[memory] Memory size in megabytes.
-\item[cpu] CPU to assign this domain to.
-\item[nics] Number of virtual network interfaces.
-\item[vif] List of MAC addresses (random addresses are assigned if not given).
-\item[disk] Regions of disk to export to the domain.
-\item[dhcp] Set to {\tt 'dhcp'} if you want to DHCP allocate the IP address.
-\item[netmask] IP netmask.
-\item[gateway] IP address for the gateway (if any).
-\item[hostname] Set the hostname for the virtual machine.
-\item[root] Set the root device.
-\item[nfs\_server] IP address for the NFS server.
-\item[nfs\_root] Path of the root filesystem on the NFS server.
-\item[extra] Extra string to append to the kernel command line.
-\item[restart] Three possible options:
- \begin{description}
- \item[always] Always restart the domain, no matter what
- its exit code is.
- \item[never] Never restart the domain.
- \item[onreboot] (restart the domain if it requests reboot).
- \end{description}
-\end{description}
-
-It is also possible to include Python scripting commands in
-configuration files. This is done in the \path{xmdefconfig} file in
-order to handle the {\tt vmid} variable.
-
-
-\chapter{Xend (Node control daemon)}
-\label{cha:xend}
-
-The Xen Daemon (Xend) performs system management functions related to
-virtual machines. It forms a central point of control for a machine
-and can be controlled using an HTTP-based protocol. Xend must be
-running in order to start and manage virtual machines.
-
-Xend must be run as root because it needs access to privileged system
-management functions. A small set of commands may be issued on the
-Xend command line:
-
-\begin{tabular}{ll}
-\verb_# xend start_ & start Xend, if not already running \\
-\verb_# xend stop_ & stop Xend if already running \\
-\verb_# xend restart_ & restart Xend if running, otherwise start it \\
-\end{tabular}
-
-A SysV init script called {\tt xend} is provided to start Xend at boot
-time. {\tt make install} installs this script in {\path{/etc/init.d}.
-To enable it, you have to make symbolic links in the appropriate
-runlevel directories or use the {\tt chkconfig} tool, where available.
-
-Once Xend is running, more sophisticated administration can be done
-using the Xensv web interface (see Chapter~\ref{cha:xensv}).
-
-\chapter{Xensv (Web interface server)}
-\label{cha:xensv}
-
-Xensv is the server for the web control interface. It can be started
-using:\\
-\verb_# xensv start_ \\
-and stopped using:
-\verb_# xensv stop_ \\
-It will automatically start Xend if it is not already running.
-
-By default, Xensv will serve out the web interface on port 8080. This
-can be changed by editing {\tt
-/usr/lib/python2.3/site-packages/xen/sv/params.py}.
-
-Once Xensv is running, the web interface can be used to manage running
-domains and provides a user friendly domain creation wizard.
-
-\chapter{The xm tool}
-\label{cha:xm}
-
-XXX Add description of arguments and switches for all the options
-
-The xm tool is the primary tool for managing Xen from the console.
-The general format of an xm command line is:
-
-\begin{verbatim}
-# xm command [switches] [arguments] [variables]
-\end{verbatim}
-
-The available {\em switches } and {\em arguments} are dependent on the
-{\em command} chosen. The {\em variables} may be set using
-declarations of the form {\tt variable=value} and command line
-declarations override any of the values in the configuration file
-being used, including the standard variables described above and any
-custom variables (for instance, the \path{xmdefconfig} file uses a
-{\tt vmid} variable).
-
-The available commands are as follows:
-
-\begin{description}
-\item[balloon] Request a domain to adjust its memory footprint.
-\item[create] Create a new domain.
-\item[destroy] Kill a domain immediately.
-\item[list] List running domains.
-\item[shutdown] Ask a domain to shutdown.
-\item[dmesg] Fetch the Xen (not Linux!) boot output.
-\item[consoles] Lists the available consoles.
-\item[console] Connect to the console for a domain.
-\item[help] Get help on xm commands.
-\item[save] Suspend a domain to disk.
-\item[restore] Restore a domain from disk.
-\item[pause] Pause a domain's execution.
-\item[unpause] Unpause a domain.
-\item[pincpu] Pin a domain to a CPU.
-\item[bvt] Set BVT scheduler parameters for a domain.
-\item[bvt\_ctxallow] Set the BVT context switching allowance for the system.
-\item[atropos] Set the atropos parameters for a domain.
-\item[rrobin] Set the round robin time slice for the system.
-\item[info] Get information about the Xen host.
-\item[call] Call a Xend HTTP API function directly.
-\end{description}
-
-For a detailed overview of switches, arguments and variables to each command
-try
-\begin{verbatim}
-# xm help command
-\end{verbatim}
-
-\chapter{Glossary}
-
-\begin{description}
-\item[Atropos] One of the CPU schedulers provided by Xen.
- Atropos provides domains with absolute shares
- of the CPU, with timeliness guarantees and a
- mechanism for sharing out ``slack time''.
-
-\item[BVT] The BVT scheduler is used to give proportional
- fair shares of the CPU to domains.
-
-\item[Exokernel] A minimal piece of privileged code, similar to
- a {\bf microkernel} but providing a more
- `hardware-like' interface to the tasks it
- manages. This is similar to a paravirtualising
- VMM like {\bf Xen} but was designed as a new
- operating system structure, rather than
- specifically to run multiple conventional OSs.
-
-\item[Domain] A domain is the execution context that
- contains a running { \bf virtual machine }.
- The relationship between virtual machines
- and domains on Xen is similar to that between
- programs and processes in an operating
- system: a virtual machine is a persistent
- entity that resides on disk (somewhat like
- a program). When it is loaded for execution,
- it runs in a domain. Each domain has a
- { \bf domain ID }.
-
-\item[Domain 0] The first domain to be started on a Xen
- machine. Domain 0 is responsible for managing
- the system.
-
-\item[Domain ID] A unique identifier for a { \bf domain },
- analogous to a process ID in an operating
- system. Apart from domain
-
-\item[Full virtualisation] An approach to virtualisation which
- requires no modifications to the hosted
- operating system, providing the illusion of
- a complete system of real hardware devices.
-
-\item[Hypervisor] An alternative term for { \bf VMM }, used
- because it means ``beyond supervisor'',
- since it is responsible for managing multiple
- ``supervisor'' kernels.
-
-\item[Live migration] A technique for moving a running virtual
- machine to another physical host, without
- stopping it or the services running on it.
-
-\item[Microkernel] A small base of code running at the highest
- hardware privilege level. A microkernel is
- responsible for sharing CPU and memory (and
- sometimes other devices) between less
- privileged tasks running on the system.
- This is similar to a VMM, particularly a
- {\bf paravirtualising} VMM but typically
- addressing a different problem space and
- providing different kind of interface.
-
-\item[NetBSD/Xen] A port of NetBSD to the Xen architecture.
-
-\item[Paravirtualisation] An approach to virtualisation which requires
- modifications to the operating system in
- order to run in a virtual machine. Xen
- uses paravirtualisation but preserves
- binary compatibility for user space
- applications.
-
-\item[Shadow pagetables] A technique for hiding the layout of machine
- memory from a virtual machine's operating
- system. Used in some {\bf VMM}s to provide
- the illusion of contiguous physical memory,
- in Xen this is used during
- {\bf live migration}.
-
-\item[Virtual Machine] The environment in which a hosted operating
- system runs, providing the abstraction of a
- dedicated machine. A virtual machine may
- be identical to the underlying hardware (as
- in { \bf full virtualisation }, or it may
- differ, as in { \bf paravirtualisation }.
-
-\item[VMM] Virtual Machine Monitor - the software that
- allows multiple virtual machines to be
- multiplexed on a single physical machine.
-
-\item[Xen] Xen is a paravirtualising virtual machine
- monitor, developed primarily by the
- Systems Research Group at the University
- of Cambridge Computer Laboratory.
-
-\item[XenLinux] Official name for the port of the Linux kernel
- that runs on Xen.
-
-\end{description}
-
-\part{Advanced Topics}
-
-\chapter{Advanced Network Configuration}
-
-For simple systems with a single ethernet interface with a simple
-configuration, the default installation should work ``out of the
-box''. More complicated network setups, for instance with multiple
-ethernet interfaces and / or existing bridging setups will require
-some special configuration.
-
-The purpose of this chapter is to describe the mechanisms provided by
-xend to allow a flexible configuration for Xen's virtual networking.
-
-\section{Xen networking scripts}
-
-Xen's virtual networking is configured by 3 shell scripts. These are
-called automatically by Xend when certain events occur, with arguments
-to the scripts providing further contextual information. These
-scripts are found by default in \path{/etc/xen}. The names and
-locations of the scripts can be configured in \path{xend-config.sxp}.
-
-\subsection{\path{network}}
-
-This script is called once when Xend is started and once when Xend is
-stopped. Its job is to do any advance preparation required for the
-Xen virtual network when Xend starts and to do any corresponding
-cleanup when Xend exits.
-
-In the default configuration, this script creates the bridge
-``xen-br0'' and moves eth0 onto that bridge, modifying the routing
-accordingly.
-
-In configurations where the bridge already exists, this script could
-be replaced with a link to \path{/bin/true} (for instance).
-
-When Xend exits, this script is called with the {\tt stop} argument,
-which causes it to delete the Xen bridge and remove {\tt eth0} from
-it, restoring the normal IP and routing configuration.
-
-\subsection{\path{vif-bridge}}
-
-This script is called for every domain virtual interface. This should
-do things like configuring firewalling rules for that interface and
-adding it to the appropriate bridge.
-
-By default, this adds and removes VIFs on the default Xen bridge.
-This script can be customized to properly deal with more complicated
-bridging setups.
-
-\chapter{Advanced Scheduling Configuration}
-
-\section{Scheduler selection}
-
-Xen offers a boot time choice between multiple schedulers. To select
-a scheduler, pass the boot parameter { \tt sched=sched\_name } to Xen,
-substituting the appropriate scheduler name. Details of the schedulers
-and their parameters are included below; future versions of the tools
-will provide a higher-level interface to these tools.
-
-It is expected that system administrators configure their system to
-use the scheduler most appropriate to their needs. Currently, the BVT
-scheduler is the recommended choice, since the Atropos scheduler is
-not finished.
-
-\section{Borrowed Virtual Time}
-
-{\tt sched=bvt } (the default) \\
-
-BVT provides proportional fair shares of the CPU time. It has been
-observed to penalise domains that block frequently (e.g. IO intensive
-domains), but this can be compensated by using warping.
-
-\subsection{Global Parameters}
-
-\begin{description}
-\item[ctx\_allow]
- the context switch allowance is similar to the "quantum"
- in traditional schedulers. It is the minimum time that
- a scheduled domain will be allowed to run before being
- pre-empted. This prevents thrashing of the CPU.
-\end{description}
-
-\subsection{Per-domain parameters}
-
-\begin{description}
-\item[mcuadv]
- the MCU (Minimum Charging Unit) advance determines the
- proportional share of the CPU that a domain receives. It
- is set inversely proportionally to a domain's sharing weight.
-\item[warp]
- the amount of "virtual time" the domain is allowed to warp
- backwards
-\item[warpl]
- the warp limit is the maximum time a domain can run warped for
-\item[warpu]
- the unwarp requirement is the minimum time a domain must
- run unwarped for before it can warp again
-\end{description}
-
-\section{Atropos}
-
-{\tt sched=atropos } \\
-
-Atropos is a Soft Real Time scheduler. It provides guarantees about
-absolute shares of the CPU (with a method for optionally sharing out
-slack CPU time on a best-effort basis) and can provide timeliness
-guarantees for latency-sensitive domains.
-
-Every domain has an associated period and slice. The domain should
-receive 'slice' nanoseconds every 'period' nanoseconds. This allows
-the administrator to configure both the absolute share of the CPU a
-domain receives and the frequency with which it is scheduled. When
-domains unblock, their period is reduced to the value of the latency
-hint (the slice is scaled accordingly so that they still get the same
-proportion of the CPU). For each subsequent period, the slice and
-period times are doubled until they reach their original values.
-
-Note: don't overcommit the CPU when using Atropos (i.e. don't reserve
-more CPU than is available - the utilisation should be kept to
-slightly less than 100% in order to ensure predictable behaviour).
-
-\subsection{Per-domain parameters}
-
-\begin{description}
-\item[slice]
- The length of time per period that a domain is guaranteed.
-\item[period]
- The period over which a domain is guaranteed to receive
- its slice of CPU time.
-\item[latency]
- The latency hint is used to control how soon after
- waking up a domain should be scheduled.
-\item[xtratime]
- This is a true (1) / false (0) flag that specifies whether
- a domain should be allowed a share of the system slack time.
-\end{description}
-
-\section{Round Robin}
-
-{\tt sched=rrobin } \\
-
-The Round Robin scheduler is included as a simple demonstration of
-Xen's internal scheduler API. It is not intended for production use
---- the other schedulers included are all more general and should give
-higher throughput.
-
-\subsection{Global parameters}
-
-\begin{description}
-\item[rr\_slice]
- The maximum time each domain runs before the next
- scheduling decision is made.
-\end{description}
-
-\chapter{Privileged domains}
-
-There are two possible types of privileges: IO privileges and
-administration privileges.
-
-\section{Driver domains (IO Privileges)}
-
-IO privileges can be assigned to allow a domain to drive PCI devices
-itself. This is used to support driver domains.
-
-Setting backend privileges is currently only supported in SXP format
-config files (??? is this true - there's nothing in xmdefconfig,
-anyhow). To allow a domain to function as a backend for others,
-somewhere within the {\tt vm} element of its configuration file must
-be a {\tt backend} element of the form {\tt (backend ({\em type}))}
-where {\tt \em type} may be either {\tt netif} or {\tt blkif},
-according to the type of virtual device this domain will service.
-After this domain has been built, Xend will connect all new and
-existing {\em virtual} devices (of the appropriate type) to that
-backend.
-
-Note that:
-\begin{itemize}
-\item a block backend cannot import virtual block devices from other
-domains
-\item a network backend cannot import virtual network devices from
-other domains
-\end{itemize}
-
-Thus (particularly in the case of block backends, which cannot import
-a virtual block device as their root filesystem), you may need to boot
-a backend domain from a ramdisk or a network device.
-
-The privilege to drive PCI devices may also be specified on a
-per-device basis. Xen will assign the minimal set of hardware
-privileges to a domain that are required to control its devices. This
-can be configured in either format of configuration file:
-
-\begin{itemize}
-\item SXP Format:
- Include {\tt device} elements
- {\tt (device (pci (bus {\em x}) (dev {\em y}) (func {\em z}))) } \\
- inside the top-level {\tt vm} element. Each one specifies the address
- of a device this domain is allowed to drive ---
- the numbers {\em x},{\em y} and {\em z} may be in either decimal or
- hexadecimal format.
-\item Flat Format: Include a list of PCI device addresses of the
- format: \\ {\tt pci = ['x,y,z', ...] } \\ where each element in the
- list is a string specifying the components of the PCI device
- address, separated by commas. The components ({\tt \em x}, {\tt \em
- y} and {\tt \em z}) of the list may be formatted as either decimal
- or hexadecimal.
-\end{itemize}
-
-\section{Administration Domains}
-
-Administration privileges allow a domain to use the ``dom0
-operations'' (so called because they are usually available only to
-domain 0). A privileged domain can build other domains, set scheduling
-parameters, etc.
-
-% Support for other administrative domains is not yet available...
-
-\chapter{Xen build options}
-
-For most users, the default build of Xen will be adequate. For some
-advanced uses, Xen provides a number of build-time options:
-
-At build time, these options should be set as environment variables or
-passed on make's command-line. For example:
-
-\begin{verbatim}
-export option=y; make
-option=y make
-make option1=y option2=y
-\end{verbatim}
-
-\section{List of options}
-
-{\bf verbose=y }\\
-Enable debugging messages when Xen detects an unexpected condition.
-Also enables console output from all domains. \\
-{\bf debug=y }\\
-Enable debug assertions. Implies {\bf verbose=y }.
-(Primarily useful for tracing bugs in Xen). \\
-{\bf debugger=y }\\
-Enable the in-Xen pervasive debugger (PDB).
-This can be used to debug Xen, guest OSes, and
-applications. For more information see the
-XenDebugger-HOWTO. \\
-{\bf perfc=y }\\
-Enable performance-counters for significant events
-within Xen. The counts can be reset or displayed
-on Xen's console via console control keys. \\
-{\bf trace=y }\\
-Enable per-cpu trace buffers which log a range of
-events within Xen for collection by control
-software. For more information see the chapter on debugging,
-in the Xen Interface Manual.
-
-\chapter{Boot options}
-
-\section{Xen boot options}
-
-These options are used to configure Xen's behaviour at runtime. They
-should be appended to Xen's command line, either manually or by
-editing \path{grub.conf}.
-
-{\bf ignorebiostables }\\
- Disable parsing of BIOS-supplied tables. This may help with some
- chipsets that aren't fully supported by Xen. If you specify this
- option then ACPI tables are also ignored, and SMP support is
- disabled. \\
-
-{\bf noreboot } \\
- Don't reboot the machine automatically on errors. This is
- useful to catch debug output if you aren't catching console messages
- via the serial line. \\
-
-{\bf nosmp } \\
- Disable SMP support.
- This option is implied by 'ignorebiostables'. \\
-
-{\bf noacpi } \\
- Disable ACPI tables, which confuse Xen on some chipsets.
- This option is implied by 'ignorebiostables'. \\
-
-{\bf watchdog } \\
- Enable NMI watchdog which can report certain failures. \\
-
-{\bf noht } \\
- Disable Hyperthreading. \\
-
-{\bf badpage=$<$page number$>$[,$<$page number$>$] } \\
- Specify a list of pages not to be allocated for use
- because they contain bad bytes. For example, if your
- memory tester says that byte 0x12345678 is bad, you would
- place 'badpage=0x12345' on Xen's command line (i.e., the
- last three digits of the byte address are not
- included!). \\
-
-{\bf com1=$<$baud$>$,DPS[,$<$io\_base$>$,$<$irq$>$] \\
- com2=$<$baud$>$,DPS[,$<$io\_base$>$,$<$irq$>$] } \\
- Xen supports up to two 16550-compatible serial ports.
- For example: 'com1=9600,8n1,0x408,5' maps COM1 to a
- 9600-baud port, 8 data bits, no parity, 1 stop bit,
- I/O port base 0x408, IRQ 5.
- If the I/O base and IRQ are standard (com1:0x3f8,4;
- com2:0x2f8,3) then they need not be specified. \\
-
-{\bf console=$<$specifier list$>$ } \\
- Specify the destination for Xen console I/O.
- This is a comma-separated list of, for example:
-\begin{description}
- \item[vga] use VGA console and allow keyboard input
- \item[com1] use serial port com1
- \item[com2H] use serial port com2. Transmitted chars will
- have the MSB set. Received chars must have
- MSB set.
- \item[com2L] use serial port com2. Transmitted chars will
- have the MSB cleared. Received chars must
- have MSB cleared.
-\end{description}
- The latter two examples allow a single port to be
- shared by two subsystems (e.g. console and
- debugger). Sharing is controlled by MSB of each
- transmitted/received character.
- [NB. Default for this option is 'com1,tty'] \\
-
-{\bf conswitch=$<$switch-char$><$auto-switch-char$>$ } \\
- Specify how to switch serial-console input between
- Xen and DOM0. The required sequence is CTRL-<switch-char>
- pressed three times. Specifying '`' disables switching.
- The <auto-switch-char> specifies whether Xen should
- auto-switch input to DOM0 when it boots -- if it is 'x'
- then auto-switching is disabled. Any other value, or
- omitting the character, enables auto-switching.
- [NB. Default for this option is 'a'] \\
-
-{\bf nmi=xxx } \\
- Specify what to do with an NMI parity or I/O error. \\
- 'nmi=fatal': Xen prints a diagnostic and then hangs. \\
- 'nmi=dom0': Inform DOM0 of the NMI. \\
- 'nmi=ignore': Ignore the NMI. \\
-
-{\bf dom0\_mem=xxx } \\
- Set the maximum amount of memory for domain0. \\
-
-{\bf tbuf\_size=xxx } \\
- Set the size of the per-cpu trace buffers, in pages
- (default 1). Note that the trace buffers are only
- enabled in debug builds. Most users can ignore
- this feature completely. \\
-
-{\bf sched=xxx } \\
- Select the CPU scheduler Xen should use. The current
- possibilities are 'bvt', 'atropos' and 'rrobin'. The
- default is 'bvt'. For more information see
- Sched-HOWTO.txt. \\
-
-{\bf pci\_dom0\_hide=(xx.xx.x)(yy.yy.y)... } \\
-Hide selected PCI devices from domain 0 (for instance, to stop it
-taking ownership of them so that they can be driven by another
-domain). Device IDs should be given in hex format. Bridge devices do
-not need to be hidden --- they are hidden implicitly, since guest OSes
-do not need to configure them.
-
-\section{XenLinux Options}
-
-{\bf xencons=xxx}
-Specify the device node to
-which the Xen virtual console driver is attached: \\
- 'xencons=off': disable virtual console \\
- 'xencons=tty': attach console to /dev/tty1 (tty0 at boot-time) \\
- 'xencons=ttyS': attach console to /dev/ttyS0\\
-The default is ttyS for dom0 and tty for all other domains.
-
-\chapter{Further Support}
-
-If you have questions that are not answered by this manual, the
-sources of information listed below may be of interest to you. Note
-that bug reports, suggestions and contributions related to the
-software (or the documentation) should be sent to the Xen developers'
-mailing list (address below).
-
-\section{Other documentation}
-
-For developers interested in porting operating systems to Xen, the
-{\em Xen Interface Manual} is distributed in the \path{docs/}
-directory of the Xen source distribution. Various HOWTOs are
-available in \path{docs/HOWTOS} but this content is being integrated
-into this manual.
-
-\section{Online references}
-
-The official Xen web site is found at: \\
-{\tt
-http://www.cl.cam.ac.uk/Research/SRG/netos/xen/] }.
-
-Links to other
-documentation sources are listed at: \\ {\tt
-http://www.cl.cam.ac.uk/Research/SRG/netos/xen/documentation.html}.
-
-\section{Mailing lists}
-
-There are currently two official Xen mailing lists:
-
-\begin{description}
-\item[xen-devel@lists.sourceforge.net] Used for development
-discussions and requests for help. Subscribe at: \\
-{\tt http://lists.sourceforge.net/mailman/listinfo/xen-devel}
-\item[xen-announce@lists.sourceforge.net] Used for announcements only.
-Subscribe at: \\
-{\tt http://lists.sourceforge.net/mailman/listinfo/xen-announce}
-\item[xen-changelog@lists.sourceforge.net] Changelog feed
-from the unstable and 2.0 trees - developer oriented. Subscribe at: \\
-{\tt http://lists.sourceforge.net/mailman/listinfo/xen-changelog}
-\end{description}
-
-Although there is no specific user support list, the developers try to
-assist users who post on xen-devel. As the bulk of traffic on this
-list increases, a dedicated user support list may be introduced.
-
-\appendix
-
-\chapter{Installing Debian}
-
-The Debian project provides a tool called {\tt debootstrap} which
-allows a base Debian system to be installed into a filesystem without
-requiring the host system to have any Debian-specific software (such
-as {\tt apt}).
-
-Here's some info how to install Debian 3.1 (Sarge) for an unprivileged
-Xen domain:
-
-\begin{enumerate}
-\item Set up Xen 2.0 and test that it's working, as described earlier in
- this manual.
-
-\item Create disk images for root-fs and swap (alternatively, you
- might create dedicated partitions, LVM logical volumes, etc. if
- that suits your setup).
-\begin{verbatim}
-dd if=/dev/zero of=/path/diskimage bs=1024k count=size_in_mbytes
-dd if=/dev/zero of=/path/swapimage bs=1024k count=size_in_mbytes
-\end{verbatim}
- If you're going to use this filesystem / diskimage only as a
- `template' for other vm diskimages, something like 300 MB should
- be enough.. (of course it depends what kind of packages you are
- planning to install to the template)
-
-\item Create the filesystem and initialise the swap image
-\begin{verbatim}
-mkfs.ext3 /path/diskimage
-mkswap /path/swapimage
-\end{verbatim}
-
-\item Mount the diskimage for installation
-\begin{verbatim}
-mount -o loop /path/diskimage /mnt/disk
-\end{verbatim}
-
-\item Install {\tt debootstrap}
-
-Make sure you have debootstrap installed on the host. If you are
-running Debian sarge (3.1 / testing) or unstable you can install it by
-running {\tt apt-get install debootstrap}. Otherwise, it can be
-downloaded from the Debian project website.
-
-\item Install debian base to the diskimage:
-\begin{verbatim}
-debootstrap --arch i386 sarge /mnt/disk \
- http://ftp.<countrycode>.debian.org/debian
-\end{verbatim}
-
-You can use any other Debian http/ftp mirror you want.
-
-\item When debootstrap completes successfully, modify settings:
-\begin{verbatim}
-chroot /mnt/disk /bin/bash
-\end{verbatim}
-
-Edit the following files using vi or nano and make needed changes:
-\begin{verbatim}
-/etc/hostname
-/etc/hosts
-/etc/resolv.conf
-/etc/network/interfaces
-/etc/networks
-\end{verbatim}
-
-Set up access to the services, edit:
-\begin{verbatim}
-/etc/hosts.deny
-/etc/hosts.allow
-/etc/inetd.conf
-\end{verbatim}
-
-Add Debian mirror to:
-\begin{verbatim}
-/etc/apt/sources.list
-\end{verbatim}
-
-Create fstab like this:
-\begin{verbatim}
-/dev/sda1 / ext3 errors=remount-ro 0 1
-/dev/sda2 none swap sw 0 0
-proc /proc proc defaults 0 0
-\end{verbatim}
-
-Logout
-
-\item Umount the diskimage
-\begin{verbatim}
-umount /mnt/disk
-\end{verbatim}
-
-\item Create Xen 2.0 configuration file for the new domain. You can
- use the example-configurations coming with xen as a template.
-
- Make sure you have the following set up:
-\begin{verbatim}
-disk = [ 'file:/path/diskimage,sda1,w', 'file:/path/swapimage,sda2,w' ]
-root = "/dev/sda1 ro"
-\end{verbatim}
-
-\item Start the new domain
-\begin{verbatim}
-xm create -f domain_config_file
-\end{verbatim}
-
-Check that the new domain is running:
-\begin{verbatim}
-xm list
-\end{verbatim}
-
-\item Attach to the console of the new domain.
- You should see something like this when starting the new domain:
-
-\begin{verbatim}
-Started domain testdomain2, console on port 9626
-\end{verbatim}
-
- There you can see the ID of the console: 26. You can also list
- the consoles with {\tt xm consoles"}. (ID is the last two
- digits of the portnumber.)
-
- Attach to the console:
-
-\begin{verbatim}
-xm console 26
-\end{verbatim}
-
- or by telnetting to the port 9626 of localhost (the xm console
- progam works better).
-
-\item Log in and run base-config
-
- As a default there's no password for the root.
-
- Check that everything looks OK, and the system started without
- errors. Check that the swap is active, and the network settings are
- correct.
-
- Run {\tt /usr/sbin/base-config} to set up the Debian settings.
-
- Set up the password for root using passwd.
-
-\item Done. You can exit the console by pressing {\tt Ctrl + ]}
-
-\end{enumerate}
-
-If you need to create new domains, you can just copy the contents of
-the `template'-image to the new disk images, either by mounting the
-template and the new image, and using {\tt cp -a} or {\tt tar} or by
-simply copying the image file. Once this is done, modify the
-image-specific settings (hostname, network settings, etc).
-
-\end{document}
-
-
-%% Other stuff without a home
-
-%% Instructions Re Python API
-
-%% Other Control Tasks using Python
-%% ================================
-
-%% A Python module 'Xc' is installed as part of the tools-install
-%% process. This can be imported, and an 'xc object' instantiated, to
-%% provide access to privileged command operations:
-
-%% # import Xc
-%% # xc = Xc.new()
-%% # dir(xc)
-%% # help(xc.domain_create)
-
-%% In this way you can see that the class 'xc' contains useful
-%% documentation for you to consult.
-
-%% A further package of useful routines (xenctl) is also installed:
-
-%% # import xenctl.utils
-%% # help(xenctl.utils)
-
-%% You can use these modules to write your own custom scripts or you can
-%% customise the scripts supplied in the Xen distribution.
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
- <title>Xen Configuration Syntax</title>
-</head>
-<body>
-<center>
-<h1>Xen Configuration Syntax</h1>
-<br>
-<!-- Version 0.1<br>2004 June 21<br> -->
-Version 0.2<br>2004 July 19<br>
-</center>
-
-<h1>Xen Configuration</h1>
-The Xen virtual machine creation tools provide command-line interfaces and
-HTTP interfaces to creating virtual machines. Underneath all these interfaces
-virtual machine configuration data is represented in a common configuration syntax
-called SXP.
-
-The SXP syntax is s-expressions (sxprs), a simple bracketed abstract syntax.
-Python lists are used to represent its parsed form, with a support
-api providing access to fields and values (class xen.xend.sxp).
-
-<h1>SXP syntax</h1>
-<p>A general s-expression has the syntax:
-<code><pre>
-s-exp = '(' s-exp* ')' | atom | string
-</pre></code>
-Where an <code>atom</code> is an unquoted string, such as fred or /domain/0.
-A <code>string</code> is a quoted string, supporting the usual escape sequences.
-Strings support single or double quotes: 'fred 1' or "fred 2" are both accepted.
-The characters ()[]<>{} are separators.
-
-<p>An <code>element</code> is an s-expression representing data similar to XML.
-It has the form:
-<code><pre>
-element = '(' name attributes? value* ')'
-name = atom
-attributes = '(' '@' attribute* ')'
-attribute = '(' attrname attrval ')'
-attrname = atom
-attrval = atom | string
-value = element | atom | string
-</pre></code>
-The <code>name</code> is the element name (roughly indentifying its type).
-The <code>attributes</code> is a list of attribute-values.
-We usually prefer to avoid using attributes, and use sub-elements instead.
-As in XML, any element may have the attribute <code>id</code> to give it an identifier
-for later reference.
-
-<h1>VM configuration</h1>
-A vm configuration is a single SXP vm element, with subelements for
-vm parameters and devices. The supported elements and their fields
-are listed below.
-
-<h2>(vm) element</h2>
-The top-level element, a virtual machine configuration.
-<ul>
- <li>name: string, required. Domain name.
- <li>id: int, optional, default generated. Domain unique id.
- <li>memory: int, required. Domain memory in MB.
- <li>maxmem: int, optional. Maximum domain memory in MB.
- <li>cpu: int, optional. Cpu to run on.
- <li>cpu_weight, float, optional, default 1. Cpu weight - controls share of CPU.
- <li>image: linux | netbsd | ..., required. Domain image (OS-specific element).
- <li>backend: any backend device type, optional, default none.
- <li>device: any device type, optional, repeats. Device.
- <li>restart: string, optional, default onreboot. Restart mode, one of
- <ul><li>onreboot: restart the domain when it exits with code reboot.
- <li>always: always restart the domain when it exits.
- <li>never: never restart the domain.
- </ul>
- <li>console: int, optional, default 9600 + domain id. Console port.
-</ul>
-
-<h2>(image (linux)) element</h2>
-Defines a linux kernel image and its command-line parameters.
-<ul>
- <li>kernel: string, required. Kernel image file (absolute path).
- <li>root: string, optional. Root device.
- <li>ip: string, optional. IP address specifier.
- <li>ramdisk: string, optional, default none. Ramdisk file (absolute path).
- <li>args: string, optional. Extra kernel args.
-</ul>
-
-<h2>(image (netbsd)) element</h2>
-Defines a netbsd kernel image and its command-line parameters.
-<ul>
- <li>kernel: string, required. Kernel image file.
- <li>root: string, optional. Root device.
- <li>ip: string, optional. IP address specifier.
- <li>ramdisk: string, optional, default none. Ramdisk file.
- <li>args: string, optional. Extra kernel args.
-</ul>
-
-<h2>(backend (blkif)) element</h2>
-The vm is a block device backend.
-The vm can have pci devices configured.
-
-<h2>(backend (netif)) element</h2>
-The vm is a net device backend.
-
-<h2>(device (vif)) element</h2>
-Defines a virtual network interface.
-<ul>
- <li>mac: string, required. Interface MAC address.
- <li>bridge: string, optional, default system-dependent. Bridge to connect to.
- <li>script: string, optional, default system-dependent. Vif script to use
- when bringing the interface up or down.
- <li>ip: IP address, optional, no default. May be repeated. An IP address
- or CIDR-format subnet the vif may use.
- <li>backend: domain name or id, optional, default 0.
- Defines the domain to use as the backend for the interface.
-</ul>
-
-<h2>(device (vbd)) element</h2>
-Defines a virtual block device.
-<ul>
- <li>uname: string, required. Virtual block device id, e.g phys:hda1.
- <li>dev: string, required. Device file name in domain, e.g. xda1.
- <li>mode: string, optional, default r. Read-write mode: r | rw | w.
- <li>backend: domain name or id, optional, default 0.
- Defines the domain to use as the backend for the device.
-</ul>
-The uname field defines the device being exported from the block device
-controller. The dev field defines the device name the vm will see.
-The device is read-only unless the mode contains w.
-
-<h2>(device (pci)) element</h2>
-Defines a pci device.
-<ul>
- <li>bus: int, required. PCI bus id.
- <li>dev: int, required. PCI dev id.
- <li>func: int, required. PCI func id.
-</ul>
-The bus, dev or func may be given in hex,
-e.g. 0xff. With no leading 0x they are interpreted as decimal.
-
-<h2>(vnet) element</h2>
-Defines the virtual networks associated with vifs (may go away soon).
-Contains a list of vif elements:
-<ul>
- <li>id: id of the vif being configured.
- <li>vnet: id of vnet the vif is assigned to.
-</ul>
-
-<h1>Examples</h1>
-<p> A vm with 64 MB memory, root on /dev/xda1 (mapped from /dev/hda1),
-one vif with default MAC.
-<code><pre>
-(vm
- (name xendom1)
- (memory 64)
- (image
- (linux
- (kernel /boot/vmlinuz-2.4.26-xen)
- (ip ::::xendom1:eth0:dhcp)
- (root /dev/xda1)
- (args 'rw fastboot 4')
- )
- )
- (device (vif))
- (device (vbd (uname phy:hda1) (dev xda1) (mode w)))
-)
-</pre></code>
-
-<p>A vm with 64 MB memory, NFS root, and 2 vifs on separate vnets.
-<code><pre>
-(vm
- (name xendom2)
- (memory 64)
- # Define a linux image.
- (image
- (linux
- (kernel "/boot/vmlinuz-2.4.26-xen")
- (ip "::::xendom2:eth0:dhcp")
- (root "/dev/nfs")
- (args "rw fastboot nfsroot=15.144.25.79:/opt/xen/xendom2 4")
- )
- )
- # Define some vifs, with ids for use later.
- (device (vif (@ (id vif1)) (mac aa:00:00:00:00:12)))
- (device (vif (@ (id vif2)) (mac aa:00:00:00:10:12)))
-
- # Configure vnets. Refer to vifs by id.
- (vnet (vif (id vif1) (vnet 1))
- (vif (id vif2) (vnet 2)))
-
-)
-</pre></code>
-
-</body>
-</html>
+++ /dev/null
-% -*- mode: LaTeX -*-
-\def\seca{\chapter}
-\def\secb{\section}
-\def\secc{\subsection}
-\def\secd{\subsubsection}
-\def\refa{chapter}
-\def\refb{section}
-\def\refc{section}
-\def\refd{section}
-
-%\def\seca{\section}
-%\def\secb{\subsection}
-%\def\secc{\subsubsection}
-%\def\refa{section}
-%\def\refb{section}
-%\def\refc{section}
-
-\documentclass[11pt,twoside,final,openright]{xenstyle}
-\usepackage{a4,graphicx,setspace}
-\setstretch{1.15}
-\input{style.tex}
-
-\begin{document}
-
-% TITLE PAGE
-\pagestyle{empty}
-\begin{center}
-\vspace*{\fill}
-\includegraphics{eps/xenlogo.eps}
-\vfill
-\vfill
-\vfill
-\begin{tabular}{l}
-{\Huge \bf Xend} \\[4mm]
-{\huge Xen v2.0 for x86} \\[80mm]
-
-{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
-{\Large University of Cambridge, UK} \\[20mm]
-{\large Last updated 30 August 2004}
-\end{tabular}
-\vfill
-\end{center}
-\cleardoublepage
-
-% TABLE OF CONTENTS
-\pagestyle{plain}
-\pagenumbering{roman}
-{ \parskip 0pt plus 1pt
- \tableofcontents }
-\cleardoublepage
-% PREPARE FOR MAIN TEXT
-\pagenumbering{arabic}
-\raggedbottom
-\widowpenalty=10000
-\clubpenalty=10000
-\parindent=0pt
-\renewcommand{\topfraction}{.8}
-\renewcommand{\bottomfraction}{.8}
-\renewcommand{\textfraction}{.2}
-\renewcommand{\floatpagefraction}{.8}
-
-\setstretch{1.15}
-
-\seca{Introduction}
-Xend is the control daemon used to manage a machine running the Xen hypervisor.
-Xend is responsible for creating and destroying domains and managing their
-resources, such as virtual block devices and virtual network interfaces.
-
-Xend exists because the Xen hypervisor itself only manages the memory image
-of a domain and its scheduling. Xen provides the event channels that connect
-a domain to its devices, but is intentionally not involved in setting them up.
-
-Xend runs as a daemon in the privileged domain 0 and uses a low-level api
-to communicate with Xen via the domain 0 kernel. Xend exports its control
-interface to its clients using HTTP. Most programming languages have
-HTTP client libraries, so this interface can be used from most popular
-languages, for example Python, Perl, C, Java.
-Xend itself is written in Python, as are most of the Xen tools.
-
-The xend interface is intended to be a complete interface for the creation
-and management of domains. It supports domain creation, shutdown, reboot,
-destruction, save, restore and migration.
-
-When xend creates a domain it creates the domain memory image and communicates
-with the device driver domain(s) to configure the devices for the domain.
-This sets up connections between the domain and backend device controllers
-in the driver domain. When a domain shuts down its memory image cannot be fully released
-unless its backend devices are released and disconnected. This is done by xend.
-In order to protect against loss of this information when xend is restarted,
-xend maintains a persistent database of domain configurations. This allows
-xend to be stopped and restarted without loss of configuration information.
-For example, in order to upgrade the xend software.
-
-\seca{Domain lifecycle}
-\secb{Domain creation}
-Xend is instructed to create a domain by posting a domain\_create message to it,
-containing the domain configuration to be instantiated. The domain configuration
-is in sxp format and is as far as possible {\em fully-bound}, that is, all
-parameters are fully-specified. The domain configuration is saved in the filesystem
-so that it can be reused later if necessary.
-
-The domain configuration specifies the domain name, memory size, kernel image
-and parameters, and all the domain devices. Xend uses the Xen api to create
-the domain memory image, and then {\em builds} the memory image for the domain
-using the kernel image. At this point the domain exists, but it cannot be run because
-it has no devices. Xend then communicates with the device driver domain to create
-the configured devices. Once the devices are created it sets up event channels
-for them between the driver domain and the new domain, and notifies the new domain
-that its devices are connected. At this point the domain can be started.
-
-Xend is also responsible for managing domain consoles. When a domain is created,
-xend sets up a console event channel to the domain, and creates a TCP listening port
-for the domain console. When a connection is accepted to the port, xend
-connects input and output for the port to the domain console channel.
-
-\secb{Domain destruction}
-When a domain terminates, because it has been shutdown or it has crashed, the
-domain resources must be released so that the domain memory image can be
-finally removed from xen. Xend monitors the domains, and is also signaled by
-xen (using a VIRQ) when a domain exits. Xend examines the domain states and
-determines which domains have exited. It then communicates with the driver domain
-to release the devices for exited domains. Xend also closes any open console
-connections and removes the TCP listeners for exited domains.
-Once all devices have been released it instructs xen to destroy the memory image.
-
-\secb{Domain restart}
-Domain restart is the xen equivalent of a machine reboot. When a domain
-exits because it has been shutdown in reboot mode, its exit code is reboot.
-When examining domains to find those that have exited and destroy them,
-xend detects those that have exited for reboot and does not completely destroy
-them. It disconnects all their devices, and detaches the console listener
-from its channel to the domain, but does not close it. Instead it schedules
-a call to rebuild the domain from its configuration. This proceeds almost
-identically to creating the domain, except that the console listener is
-reused and connected to the new domain. This allows existing console
-connections to remain connected across a domain restart. The restarted
-domain keeps the same name and domain id.
-
-The determination of when to restart a domain is in fact slightly more
-complex than described above. A domain is configured with a
-{\em restart mode}. If the restart mode is {\em onreboot}, the default,
-restart happens when the domain is shutdown normally and
-exits with code reboot. If the restart mode is {\em never} the domain is
-not restarted. If the restart mode is {\em always} the domain is always
-restarted, regardless of how it exited.
-
-In order to prevent continual domain crash causing restart loops, xend
-has a {\em minimum restart time}. Xend remembers when a domain was last
-restarted and will fail a restart that happens inside the minimum
-restart time.
-
-\seca{Devices}
-\secb{Virtual network interfaces}
-Each virtual network interface (vif) has 2 parts: the font-end device in its domain,
-and the back-end device in the driver domain. Usually the driver domain is domain 0,
-and there is a linux network device corresponding to the vif. The linux device for
-interface N on domain D is called vifD.N. When a packet is sent on the vif in the
-domain the packet is received from the linux device. The linux devices are connected
-to network interfaces using ethernet bridging.
-
-The default setup is a bridge xen-br0, with eth0 connected to it, and the routes
-for eth0 directed at xen-br0. This is controlled by the xend network setup script,
-default {\tt /etc/xen/network}, which is run when xend starts.
-
-When the vifs for a domain are created, a vif control script, default {\tt /etc/xen/vif-bridge},
-is run to connect the vif to its bridge. The default script connects the vif
-to xen-br0 and optionally sets up iptables rules to prevent IP address spoofing.
-The bridge a vif is connected to can be defined in its configuration, and this is useful
-for setting up virtual networks using several bridges.
-
-\secb{Virtual block devices}
-Virtual block devices in a domain are interfaces onto back-end device drivers
-that export physical devices to domains. In the default configuration the back-end
-driver is in domain 0 and can export any linux block device to a domain. This includes
-physical disk partitions, LVM volumes and loopback mounts of files. In fact anything
-that linux can represent as a block device can be exported to a domain as virtual
-block device.
-
-\seca{Xend invocation}
-Xend is started (by root) using the command
-\begin{verbatim}
-xend start
-\end{verbatim}
-Xend can be stopped using
-\begin{verbatim}
-xend stop
-\end{verbatim}
-Xend must be started before any domains (apart from domain 0) can be created.
-If you try to use the {\tt xm} tool when xend is not running you will get a
-'connection refused' message.
-
-\secb{Xend configuration}
-Xend reads its own configuration from {\tt /etc/xen/xend-config.sxp}, which is
-a sequence of s-expressions. The configuration parameters are:
-\begin{itemize}
-
-\item xend-port: Port xend should use for the HTTP interface (default 8000).
-
-\item xend-address: Address xend should listen on.
- Specifying 'localhost' prevents remote connections.
- Specifying the empty string '' allows all connections, and is the default.
-
-\item network-script: The script used to start/stop networking for xend (default network).
-
-\item vif-bridge: The default bridge that virtual interfaces should be connected to
- (default xen-br0).
-
-\item vif-script: The default script used to control virtual interfaces
- (default vif-bridge).
-
-\item vif-antispoof: Whether iptables should be set up to prevent IP spoofing for
- virtual interfaces (default yes).
-\end{itemize}
-
-Configuration scripts ({\it e.g.} for network-script) are looked for in {\tt /etc/xen}
-unless their name begins with '/'.
-
-Xend sends its log output to {\tt /var/log/xend.log}. This is a rotating logfile,
-and logs are moved onto {\tt xend.log.1} {\it etc.} as they get large. Old logs may
-be deleted.
-
-\secb{Xend database}
-Xend needs to make some data persistent, and it uses files under {\tt /var/xen/xend-db}
-for this. The persistent data is stored in files in SXP format. Domain information
-is saved when domains are created. When xend starts it reads the file {\tt /var/xen/lastboot}
-(if it exists) to determine the last time the system was rebooted. It compares this time
-with the last reboot time in {\tt wtmp} to determine if the system has been rebooted
-since xend last ran. If the system has been rebooted xend removes all its saved data
-that is not persistent across reboots (for example domain data).
-
-\seca{Xend HTTP Interface}
- The xend interface uses HTTP 1.1 \cite{http} as its transport.
-Simple PUT and GET calls can encode parameters using the standard url-encoding
-for parameters: MIME type {\tt application/x-www-form-urlencoded}.
-When file upload is required, the {\tt multipart/form-data} encoding is used.
-See the HTML 4.1 specification for details \cite{html}.
-
-Xend functions as a webserver and supports two interfaces: one
-for web-browsers and one for programs.
-The web-browser interface returns replies in HTML and includes forms
-for interactive operations such as stopping domains and creating domains
-from an uploaded configuration. The programmatic interface usually returns replies
-in s-expression format. Both interfaces are accessed
-in exactly the same way over HTTP - the only difference is the data returned.
-
-The webserver distinguishes browsers from programs using the {\tt User-Agent}
-and {\tt Accept} headers in the HTTP request. If there is no {\tt User-Agent} or no
-{\tt Acccept} header, or {\tt Accept} includes the type {\tt application/sxp}, the
-webserver assumes the client is a program and returns SXP. Otherwise
-it assumes the client is a webserver and returns HTML.
-In some cases the return value is essentially a string, so {\tt Content-Type}
-{\tt text/plain} is returned.
-
-The HTTP api supported is listed below. All paths in it are relative to the
-server root, for example {\tt http://localhost:8000/xend}.
-As defined in the HTTP specification, we use GET for side-effect free
-operations that may safely be repeated, and POST for operations with
-side-effects. For each request we list the HTTP method (GET or POST),
-the url relative to the server root, the operation name and arguments (if any).
-The operation name is passed as request parameter 'op', and the arguments
-are passed by name. Operation name and parameters can be encoded using either
-encoding described above. We also list the corresponding api function from the
-Python client interface in {\tt xen.xend.XendClient}.
-
-\begin{itemize}
-\item {\tt GET /},\\
- {\tt xend()}:\\
- Get list of urls under xend root.
-
-\item {\tt GET /node},\\
- {\tt xend\_node()}:\\
- Get node information.
-
-\item {\tt POST /node shutdown()},\\
- {\tt xend\_node\_shutdown()}:\\
- Shutdown the node
-
-\item {\tt POST /node reboot()},\\
- {\tt xend\_node\_reboot()}:\\
- Reboot the node
-
-\item {\tt POST /node notify()}:\\
- Set node notification url
-
-\item {\tt GET /node/dmesg},\\
- {\tt xend\_node\_dmesg()}:\\
- Get xen boot message.
-
-\item {\tt GET /node/log},\\
- {\tt xend\_node\_log()}:\\
- Get xend log.
-
-\item {\tt GET /domain}\\
- {\tt xend\_domains()}:\\
- Get list of domains.
-
-\item {\tt POST /domain create(config)},\\
- {\tt xend\_domain\_create(config)}:\\
- Create a domain.
-
-\item {\tt POST /domain restore(file)},\\
- {\tt xend\_domain\_restore(filename)}:\\
- Restore a saved domain.
-
-\item {\tt GET /domain/<dom>},\\
- {\tt xend\_domain(dom)}:\\
- Get domain information.
-
-\item {\tt POST /domain/[dom] configure(config)},\\
- {\tt xend\_domain\_configure(dom, conf)}:\\
- Configure an existing domain (for internal use by restore and migrate).
-
-\item {\tt POST /domain/[dom] unpause()},\\
- {\tt xend\_domain\_unpause(dom)}:\\
- Start domain running
-
-\item {\tt POST /domain/[dom] pause()},\\
- {\tt xend\_domain\_pause(dom)}:\\
- Stop domain running.
-
-\item {\tt POST /domain/[dom] shutdown(reason)},\\
- {\tt xend\_domain\_shutdown(dom, reason)}:\\
- Shutdown domain, reason can be reboot, poweroff, halt.
-
-\item {\tt POST /domain/[dom] destroy(reason)},\\
- {\tt xend\_domain\_destroy(dom, reason)}:\\
- Destroy domain, reason can be reboot, halt.
-
-\item {\tt POST /domain/[dom] save(file)},\\
- {\tt xend\_domain\_save(dom, filename)}:\\
- Save a domain to a file.
-
-\item {\tt POST /domain/[dom] migrate(dst)},\\
- {\tt xend\_domain\_migrate(dom, dst)}:\\
- Migrate a domain.
-
-\item {\tt POST /domain/[dom] pincpu(cpu)},\\
- {\tt xend\_domain\_pincpu(self, id, cpu)}\\:
- Pin a domain to a cpu.
-
-\item {\tt POST /domain/[dom] bvt\_set(mcuadv, warp, warpl, warpu)},\\
- {\tt xend\_domain\_cpu\_bvt\_set(dom, mcuadv, warp, warpl, warpu)}:\\
- Set BVT scheduler parameters.
-
-\item {\tt POST /domain/[dom] atropos\_set(period, slice, latency, xtratime)},\\
- {\tt xend\_domain\_cpu\_atropos\_set(dom, period, slice, latency, xtratime)}:\\
- Set atropos scheduler parameters.
-
-\item {\tt POST /domain/[dom] maxmem\_set(memory)},\\
- {\tt xend\_domain\_maxmem\_set(dom, memory)}:\\
- Set domain maximum memory limit.
-
-\item {\tt POST /domain/[dom] device\_create(config)}\\
- {\tt xend\_domain\_device\_create(dom, config)}:\\
- Add a device to a domain.
-
-\item {\tt POST /domain/[dom] device\_destroy(type, index)},\\
- {\tt xend\_domain\_device\_destroy(dom, type, index)}:\\
- Delete a device from a domain
-
-\item {\tt GET /domain/[dom] vifs()},\\
- {\tt xend\_domain\_vifs(dom)}:\\
- Get virtual network interfaces.
-
-\item {\tt GET /domain/[dom] vif(vif)},\\
- {\tt xend\_domain\_vif(dom, vif)}:\\
- Get virtual network interface.
-
-\item {\tt GET /domain/[dom] vbds()},\\
- {\tt xend\_domain\_vbds(dom)}:\\
- Get virtual block devices.
-
-\item {\tt GET /domain/[dom] vbd(vbd)},\\
- {\tt xend\_domain\_vbd(dom, vbd)}:\\
- Get virtual block device.
-
-\item {\tt GET /console},\\
- {\tt xend\_consoles()}:\\
- Get list of consoles.
-
-\item {\tt GET /console/[id]}\\
- {\tt xend\_console(id)}:\\
- Get information about a console.
-
-\item {\tt GET /console/[id] disconnect()}\\
- {\tt xend\_console\_disconnect(self, id)}:\\
- Disconnect any console TCP connection.
-
-\item {\tt GET /vnet}\\
- {\tt xend\_vnets()}:\\
- Get list of vnets (virtual networks).
-
-\item {\tt GET /vnet/[id]}\\
- {\tt xend\_vnet(id)}:\\
- Get information about a virtual network.
-
-\item {\tt POST /vnet create(config)}\\
- {\tt xend\_vnet\_create(conf)}:\\
- Create a vnet.
-
-\item {\tt POST /vnet/[id] delete()}\\
- {\tt xend\_vnet\_delete(id)}:\\
- Delete a vnet.
-
-\item {\tt POST /event inject(event)}\\
- {\tt xend\_event\_inject(sxpr)}:\\
- Inject an event.
-
-\end{itemize}
-
-\secb{Xend debugging interface}
-Xend also listens on port 8001. Connecting to this port (for example via telnet)
-allows access to some debugging functions:
-\begin{itemize}
-\item help: list functions
-\item traceon: turn xend tracing on
-\item traceoff: turn xend tracing off
-\item quit: disconnect.
-\item info: list console listeners, block and network device controllers.
-\end{itemize}
-
-When tracing is on xend logs all functions calls and exceptions to
-{\tt /var/log/xend.trace}.
-
-\begin{thebibliography}{99}
-
-\bibitem{html}
-HTML 4.01 Specification,\\
-http://www.w3.org/TR/html4/,\\
-W3C Recommendation, 24 December 1999.
-
-\bibitem{http}
-Hypertext Transfer Protocol -- HTTP/1.1,\\
-http://www.ietf.org/rfc/rfc2616.txt,\\
-RFC 2616, IETF 1999.
-
-\bibitem{ssh}
-http://www.openssh.org.
-
-\bibitem{stunnel}
-http://www.stunnel.org.
-
-\end{thebibliography}
-\end{document}
projects / xen.git / commitdiff